Ismael Barros wrote:
> Tests for CreateGroup
> Fixed the implementation of CreateGroup and CreateGroupInGroup so that
> it doesn't segfault when the service provider is not initialized
>
> ---
> dlls/dplayx/dplay.c| 10 ++
> dlls/dplayx/tests/dplayx.c | 340
> +
"Dan Hipschman" <[EMAIL PROTECTED]> wrote:
> +#include
...
> @@ -2718,8 +2719,38 @@ DWORD WINAPI GetSecurityInfo(
> PSECURITY_DESCRIPTOR *ppSecurityDescriptor
> )
> {
> - FIXME("stub!\n");
> - return ERROR_BAD_PROVIDER;
> +SECURITY_DESCRIPTOR *sd;
> +NTSTATUS status;
> +ULONG n1
Luis Busquets wrote:
> +if ((caps.VS20Caps.NumTemps>=13) &&
> +(caps.VS20Caps.DynamicFlowControlDepth=24)&&
> +(caps.VS20Caps.Caps&D3DPS20CAPS_PREDICATION))
> +{
> +return "vs_2_a";
> +}
Please re-che
> 2008/8/4 Stefan Dösinger <[EMAIL PROTECTED]>:
> > and will be done in another patch wave.
> >
> About those... could you spread them out a bit? It's quite a bit of
> code to review, and right now I probably don't look as close as I
> probably should.
Sure, I attached a dump of my git tree.
There
2008/8/4 James Hawkins <[EMAIL PROTECTED]>:
> On Mon, Aug 4, 2008 at 1:03 PM, Paul Vriens <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> The recent additions to the dplayx tests make these tests run very slow (or
>> there is just a lot tested?).
>>
>> Is there a way to either split up these tests so they
2008/8/4 Hongbo Ni <[EMAIL PROTECTED]>:
>
> Reece wrote
>
>>> I really need to compile and run existing tests on window before I can
>>> write any test case for wine.
>>
>> What is git's core.autocrlf setting configured to? I had this issue
>> (some of the detected filenames are '\r' - which is ca
On Mon, 4 Aug 2008, Jeremy Newman wrote:
> I have no intention of removing the WWN box. Removing it will leave a
> large gaping hole on that right sidebar.
Are the other patches ok?
--
Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/
I haven't lost my mind, it's ba
> 2008/8/4 Stefan Dösinger <[EMAIL PROTECTED]>:
> > +/* No checkGLcall here to avoid locking the lock just for
> checking a call that hardly ever
> > + * fails
> > + */
> I think explaining why there's no ENTER_GL()/LEAVE_GL() is more
> important there.
Good point
2008/8/4 Stefan Dösinger <[EMAIL PROTECTED]>:
> and will be done in another patch wave.
>
About those... could you spread them out a bit? It's quite a bit of
code to review, and right now I probably don't look as close as I
probably should.
2008/8/4 Stefan Dösinger <[EMAIL PROTECTED]>:
> +if(CheckDepthStencilCapability(Adapter, AdapterFormat, CheckFormat))
> return TRUE;
This is redundant, the depthstencil formats should already be caught
by the CheckTextureCapability() call. I think you should set this up
the same way as WINED3D
On Mon, Aug 4, 2008 at 3:02 PM, Austin English <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 4, 2008 at 2:57 PM, James Hawkins <[EMAIL PROTECTED]> wrote:
>> On Mon, Aug 4, 2008 at 1:03 PM, Paul Vriens <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> The recent additions to the dplayx tests make these tests ru
On Mon, Aug 4, 2008 at 2:57 PM, James Hawkins <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 4, 2008 at 1:03 PM, Paul Vriens <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> The recent additions to the dplayx tests make these tests run very slow (or
>> there is just a lot tested?).
>>
>> Is there a way to either
On Mon, Aug 4, 2008 at 1:03 PM, Paul Vriens <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The recent additions to the dplayx tests make these tests run very slow (or
> there is just a lot tested?).
>
> Is there a way to either split up these tests so they don't timeout or better
> yet find out if we can run
2008/8/4 Stefan Dösinger <[EMAIL PROTECTED]>:
> +/* No checkGLcall here to avoid locking the lock just for checking a
> call that hardly ever
> + * fails
> + */
I think explaining why there's no ENTER_GL()/LEAVE_GL() is more important there.
2008/8/4 Luis Busquets <[EMAIL PROTECTED]>:
> +#include "d3d9.h"
...
> +#define module(vx,vy,vz) sqrt((vx)*(vx)+(vy)*(vy)+(vz)*(vz))
...
> +#include "stdio.h"
You don't really need those.
I have no intention of removing the WWN box. Removing it will leave a
large gaping hole on that right sidebar.
I agree, we should also have a sidebar link for WWN back issues.
-Newman
Zachary Goldberg wrote:
> On Mon, Aug 4, 2008 at 9:28 AM, Francois Gouget <[EMAIL PROTECTED]> wrote:
>> So assu
On Mon, 2008-08-04 at 20:03 +0200, Paul Vriens wrote:
> Hi,
>
> The recent additions to the dplayx tests make these tests run very slow (or
> there is just a lot tested?).
>
> Is there a way to either split up these tests so they don't timeout or better
> yet find out if we can run them faster.
On Mon, Aug 4, 2008 at 11:08 AM, Scott Ritchie <[EMAIL PROTECTED]> wrote:
>> My understanding is that Valgrinding alone takes much more than 25
>> minutes already.
>
> Well, you could throw more hardware at it.
That's the option I like.
> Alternatively, if most patches are good, then you could te
2008/8/4 Stefan Dösinger <[EMAIL PROTECTED]>:
>> This is mostly for correctness, in practice we should always be able to
>> avoid using CTXUSAGE_BLIT for offscreen targets when FBO ORM is used.
> Not always actually. With my upcoming patches to perform YUV conversion in
> Blt I'll have to avoid the
Francois Gouget wrote:
>
> There you have to take into account that for the past week we've had an
> average of 56 patch submissions per day. So if you want the bot to keep
> up it means it must spend less than 25 minutes on each patch. But if you
> want to have a little bit of room for growth
> This is mostly for correctness, in practice we should always be able to
> avoid using CTXUSAGE_BLIT for offscreen targets when FBO ORM is used.
Not always actually. With my upcoming patches to perform YUV conversion in
Blt I'll have to avoid the fbo_blit codepath in some situations even if
fbo_bl
Hi,
The recent additions to the dplayx tests make these tests run very slow (or
there is just a lot tested?).
Is there a way to either split up these tests so they don't timeout or better
yet find out if we can run them faster. This issue can be seen on W2K upwards.
The same can be said about
Thanks for the feedback. Resubmitted.
-aric
Vitaliy Margolen wrote:
> Please bottom post on this ML.
>
> Aric Stewart wrote:
> > Here is a revised patch which builds the scancode->DIK table on
> > initialization making no xserver round trips required on lookup.
> >
> > How does this look?
>
Reece wrote
>> I really need to compile and run existing tests on window before I can write
>> any test case for wine.
>
> What is git's core.autocrlf setting configured to? I had this issue
> (some of the detected filenames are '\r' - which is caused by perl
> being confused, which then confuse
On Mon, Aug 4, 2008 at 9:28 AM, Francois Gouget <[EMAIL PROTECTED]> wrote:
> ---
>
> So assuming that all the previous patches were miraculously correct, then,
> as discussed on wine-devel, we don't need the 'Weekly Newsletters' box
> anymore.
>
> site |6 --
> 1 files changed, 0 insertion
"Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
> I run test-cases on 98 and XP and I can not see where this messages have
> been posted in tests. In Wine this messages have not processing.
>
> Does anybody something know about this?
Try to run the tests in a paletted (256 color) mode.
--
Dmitry.
> this patch fixes performance regressions in Max Payne 2, Morrowind and
> HL2 on nVidia GeforceFx based hardware.
> It has been approved by Stefan Dösinger and verified by test
> application (see source).
Just to add this here as well, I think this patch is fine. I could not find
any way to use th
On Mon, Aug 4, 2008 at 2:23 AM, Francois Gouget <[EMAIL PROTECTED]> wrote:
> On Fri, 1 Aug 2008, Huw Davies wrote:
>
>> Hi folks,
>>
>> Here's an update on the DIB engine that I've been working on for the
>> last few months.
>
> An important thing to note about this work is that its architecture
>
On Mon, Aug 4, 2008 at 5:09 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> what should really happen is that patches that fail the validation don't
> even make it to wine-patches, they get bounced to the submitter. Of
> course the bot needs to be reliable enough for this not to become a
> nuis
Hi Scott!
Three suggestions:
1) send one patch per email; use 1/2 and 2/2 in the subject line to
make it clear they're related
2) port some existing accept() conformance tests from ws2_32/tests/sock.c
to use AcceptEx(), add a bit to check the special new features,
and make sure they pass on Windows
"Dan Kegel" <[EMAIL PROTECTED]> writes:
>> * to Alexandre to use as a replacement for wine-patches so he'd have
>> more information about each patch.
>
> If he asks for it. (Maybe he'll be happy with the web site.)
what should really happen is that patches that fail the validation don't
even
On Mon, Aug 4, 2008 at 2:07 AM, Francois Gouget <[EMAIL PROTECTED]> wrote:
> I'd send the results to:
> * a website so everyone can see the status of each patch and how
> backlogged the bot is (especially when people send a series of 30
> patches at once).
Yes.
> * to Alexandre to use as a
On Mon, Aug 4, 2008 at 1:55 AM, Francois Gouget <[EMAIL PROTECTED]> wrote:
> So all the bot has to do is to run git-blame on each failure line to get
> its unique id, then check the unique id against the list of
> known/allowed (intermittent) failures, and only fail the patch if the
> failure is no
Stefan Dösinger <[EMAIL PROTECTED]> writes:
> I don't see a reason not to do this
It doesn't work here:
../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so
visual.c && touch visual.ok
visual.c:8469: Tests skipped: D3DFMT_G16R16F textures not supported
visual.c:8469: Te
Hi! Thank you for your comments
> It doesn't really matter what code pages Windows supports, it does
> matter though what code pages are valid. You need to use Win32 APIs
> EnumSystemCodePages/GetCPInfo/MultiByteToWideChar instead of accessing
> Wine internals directly.
I used EnumSystemCodePages
On Sat, 2 Aug 2008, Dan Kegel wrote:
[...]
> Question: where should the results go?
> I could put them up on a web site
> and/or email them to the patch's author
> and/or email them to a dedicated mailing list (e.g.
> [EMAIL PROTECTED])
> and/or email them to wine-devel.
I'd send the results to:
On Sat, 2 Aug 2008, Zachary Goldberg wrote:
[...]
> Its really ironic that you post this today as just yesterday I was
> contemplating the same thing, and not only doing a compile check but
> also a run of the test suite
One problem is that you need an X server, preferably on real hardware to
ple
On Fri, 1 Aug 2008, Huw Davies wrote:
> Hi folks,
>
> Here's an update on the DIB engine that I've been working on for the
> last few months.
An important thing to note about this work is that its architecture
should be acceptable to Alexandre. So it can go into WineHQ, the only
blocker being
38 matches
Mail list logo
