Alexander Nicolaysen Sørnes schrieb:
Should be a little more user-friendly.
Alexander N. Sørnes
__ NOD32 3344 (20080810) Information __
Diese E-Mail wurde vom NOD32 antivirus system geprüft
http://www.nod32.com
I think you should put the things from surface_impl.h into ddraw_private.h
-Original Message-
From: [EMAIL PROTECTED] [mailto:wine-patches-
[EMAIL PROTECTED] On Behalf Of Michael Karcher
Sent: Sunday, August 10, 2008 4:20 PM
To: [EMAIL PROTECTED]
Subject: [PATCH 03/10]
I think it is better to replace the whole macros in ddcomimpl.h with inline
functions. This is also what Alexandre asked for some time ago, but I was too
lazy to implement it
-Original Message-
From: [EMAIL PROTECTED] [mailto:wine-patches-
[EMAIL PROTECTED] On Behalf Of Michael
2008/8/10 Juan Lang [EMAIL PROTECTED]:
Why manually load iphlpapi here instead of using the automatic delayed
import mechanism like you used for ws2_32? I assume it was because you
reasoned that a hard dependency was unnecessary because the code has a
fallback path, but I think you needed to
2008/8/10 Ismael Barros [EMAIL PROTECTED]:
On 8/10/08, Dan Kegel [EMAIL PROTECTED] wrote:
Hi Ismael,
have a look at
http://test.winehq.org/data/tests/dplayx:dplayx.html
Since your commits on the 4th of Aug, the dplayx tests have been hanging.
This is getting in the way of my regression
Do you see a chance to get such a change committed?
It's hard to tell; I think you should ask Alexandre once he's back from vacation
On Sunday 10 August 2008 18:34:02 Dan Kegel wrote:
http://test.winehq.org/data/tests/dplayx:dplayx.html
Since your commits on the 4th of Aug, the dplayx tests have been hanging.
This is getting in the way of my regression testing.
I've toyed with the tests a little and the following tests
On Fri, Aug 8, 2008 at 1:05 PM, Tomasz Czapiewski [EMAIL PROTECTED] wrote:
If no then are there any plans for multiplatform code in Wine?
There are many Linux users of such hardware (like Neo FreeRunner etc.)
which would like to use Windows applications on their portable
ARM-based devices.
On Monday 11 August 2008 17:14:52 Kai Blin wrote:
test_Open() 49s
test_EnumSessions() 180s
test_CreatePlayer() 32s
test_GetPlayerAccount() 63s, also 1 test failure on XP
Skipping these four tests, the test completes in two minutes on my box, which
still is a lot of time. They probably need
On 8/11/08, Kai Blin [EMAIL PROTECTED] wrote:
On Sunday 10 August 2008 18:34:02 Dan Kegel wrote:
http://test.winehq.org/data/tests/dplayx:dplayx.html
Since your commits on the 4th of Aug, the dplayx tests have been hanging.
This is getting in the way of my regression testing.
I've toyed
On Sat, Aug 9, 2008 at 9:01 PM, Dan Kegel [EMAIL PROTECTED] wrote:
For the moment, the results only go to a web page,
http://kegel.com/wine/patchwatcher/results/
Most of the results there right now are just test messages
so you can see how it will look when real patches
with various problems
Am Montag, den 11.08.2008, 09:45 -0700 schrieb Dan Kegel:
The scripts now run conformance tests and report regressions.
Does Ditto, but just the new error:end of output mean that there are
no new errors?
Regards,
Michael Karcher
On Monday 11 August 2008 18:17:58 Ismael Barros wrote:
On 8/11/08, Kai Blin [EMAIL PROTECTED] wrote:
On Sunday 10 August 2008 18:34:02 Dan Kegel wrote:
http://test.winehq.org/data/tests/dplayx:dplayx.html
Since your commits on the 4th of Aug, the dplayx tests have been
hanging. This is
On 8/11/08, Kai Blin [EMAIL PROTECTED] wrote:
On Monday 11 August 2008 18:17:58 Ismael Barros wrote:
That's probably the main problem, as there's no network latency (all
the messages are sent to localhost) or cpu intensive operation.
Actually the thread stuff is a very good idea, I'll take a
On Mon, Aug 11, 2008 at 10:13 AM, Michael Karcher
[EMAIL PROTECTED] wrote:
Am Montag, den 11.08.2008, 09:45 -0700 schrieb Dan Kegel:
The scripts now run conformance tests and report regressions.
Does Ditto, but just the new error:end of output mean that there are
no new errors?
Yes. Sorry,
Hi all,
Dan Kegel pointed out to me a couple of tests for WinHttp were reported as
crashing in Wine, build 520ab5c26170 (the latest).
Would the owners of machines 2000 wine-1.1.2 and XP th please shoot me an
email. I'd like to see if I can reproduce the crash in wine.
For better reference,
So, git generates patches like this:
diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c
index da66e2e..4569997 100644
--- a/dlls/ddraw/tests/dsurface.c
+++ b/dlls/ddraw/tests/dsurface.c
and that's the way we like it.
And sometimes people generate patches with cvs, like
On Mon, Aug 11, 2008 at 4:51 PM, Dan Kegel [EMAIL PROTECTED] wrote:
So, git generates patches like this:
diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c
index da66e2e..4569997 100644
--- a/dlls/ddraw/tests/dsurface.c
+++ b/dlls/ddraw/tests/dsurface.c
and that's the
On Mon, Aug 11, 2008 at 2:27 PM, Zachary Goldberg [EMAIL PROTECTED] wrote:
Are there factors in this decision other than Alexandre's convenience?
He's the main voice, but others might feel strongly one way
or the other, too.
Hi,
I have one more concern.
Its regarding running of tests.
When running tests for the patch, I think we should just run the tests
of the dlls that are affected direct;y or indirectly by that change.
its running the tests for entire wine, which is very time consuming.
What will happen if we have
On Mon, Aug 11, 2008 at 4:31 PM, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
When running tests for the patch, I think we should just run the tests
of the dlls that are affected direct;y or indirectly by that change.
its running the tests for entire wine, which is very time consuming.
True,
On Mon, Aug 11, 2008 at 7:42 PM, Dan Kegel [EMAIL PROTECTED] wrote:
On Mon, Aug 11, 2008 at 4:31 PM, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
When running tests for the patch, I think we should just run the tests
of the dlls that are affected direct;y or indirectly by that change.
its
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Ok I was expressing my concern as it took around 2-3hrs to see my
patch in the patchwatcher.
It's running on a 1GHz single core machine right now.
I'll probably put it on something rather faster.
Also as you you running the wine tests all for each
On Mon, Aug 11, 2008 at 8:34 PM, Dan Kegel [EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Ok I was expressing my concern as it took around 2-3hrs to see my
patch in the patchwatcher.
It's running on a 1GHz single core machine right now.
I'll probably put it on something
On Mon, Aug 11, 2008 at 8:34 PM, Dan Kegel [EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Ok I was expressing my concern as it took around 2-3hrs to see my
patch in the patchwatcher.
It's running on a 1GHz single core machine right now.
I'll probably put it on something
Dan Kegel wrote:
On Mon, Aug 11, 2008 at 2:27 PM, Zachary Goldberg [EMAIL PROTECTED] wrote:
Are there factors in this decision other than Alexandre's convenience?
He's the main voice, but others might feel strongly one way
or the other, too.
It's been the rule for a long time when we
Zachary Goldberg [EMAIL PROTECTED] wrote:
[much quoted text]
Please trim the quotes down a bit when you reply...
Dan, how are you handling the case when Alexandre floods the list with
commits?
See refresh_tree(),
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Also add Yellow for ignored patches.
Let me think on that a bit. Probably.
For ignored patches /i would like to add a second pass, when have to
check if the patch is generated by git or not
if not patch is being ignored now, for that we need to
On Mon, Aug 11, 2008 at 11:02 PM, Dan Kegel [EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Also add Yellow for ignored patches.
Let me think on that a bit. Probably.
For ignored patches /i would like to add a second pass, when have to
check if the patch is generated
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Ahh... I forgot how to handle dependent patches, if they are not in a
patch series
I don't know if there's a good way to handle those.
Maybe just encourage people not to send them :-)
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
+BOOL WINAPI ConvertToAutoInheritPrivateObjectSecurity(
+PSECURITY_DESCRIPTOR ParentDescriptor,
+PSECURITY_DESCRIPTOR CreatorDescriptor,
+PSECURITY_DESCRIPTOR* NewDescriptor,
+GUID* ObjectType,
+BOOL
On Mon, Aug 11, 2008 at 11:52 PM, Dan Kegel [EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Ahh... I forgot how to handle dependent patches, if they are not in a
patch series
I don't know if there's a good way to handle those.
Maybe just encourage people not to send them
Zachary Goldberg [EMAIL PROTECTED] wrote:
Policy is that all patches should be independent, no?
There is no such a policy. Dependent patches are marked as
1/xx, 2/xx, ... xx/xx.
--
Dmitry.
Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Zachary Goldberg [EMAIL PROTECTED] wrote:
Policy is that all patches should be independent, no?
There is no such a policy. Dependent patches are marked as
1/xx, 2/xx, ... xx/xx.
That's a patch series, and patchwatcher handles that ok.
There's
Dan Kegel [EMAIL PROTECTED] wrote:
That's a patch series, and patchwatcher handles that ok.
There's another kind of dependent patch, where somebody
says This requires Harold's patch from yesterday.
Patchwatcher probably isn't going to handle that ever.
Well, that happens not that often, so
35 matches
Mail list logo
