Re: [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
On 04/13/2010 12:46 AM, Greg Geldorp wrote:
From: Ge van Geldorp
From: Roderick Colenbrander
I'm not sure how the bot works but it looks like it concatenated some
of my patches together and then applied to them. I have no idea to
what Wine version it was since it applies fine on Wine git here. It
could be that I'm doing something wrong but I don't see where.
No, this is the bot messing up. For some reason I don't understand yet
it included one of your earlier patches ("[PATCH 08/13] d3d9: Add an
initial ColorFill regression test.") as the first of this series. That
threw everything off.
I'll disable emailing to wine-devel until I've sorted this out.
Ok, I understand what happened now... This is the sequence of patches you
submitted, in the order they arrived in my mail queue (oldest first):
1) [PATCH 4/7] wined3d: Move D15S1 over to the formats table.
2) [PATCH 1/7] wined3d: Move L6V5U5 conversion to the formats table.
3) [PATCH 5/7] wined3d: Move R32G32F convertion to the formats table.
4) [PATCH 3/7] wined3d: Move D24X4S4 to the formats table.
5) [PATCH 6/7] wined3d: Move G16R16/R16G16F conversion to the formats table.
6) 1/3 d3d9: Add an initial ColorFill regression test.
7) [PATCH 2/7] wined3d: Move D24FS8 to formats table.
8) [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
Note the out-of-sequence arrival of number 6). The bot is not smart enough
to handle two series from the same author arriving interleaved. It will see
everything as one big series until all parts of a series have arrived. In
this case, the patch attached to message 6) overwrote the patch attached
to message 2) (both have part number 1).
Not sure how to handle this, except by asking people to leave some time
before sending another series.
Dan's Patchwatcher had more or less the same issue in the beginning, but
wasn't that solved?
I think the only issue left was when people sent 2 series of equal
patchcounts and they arrive mixed.
--
Cheers,
Paul.
Re: winmm: MCI system commands are not eligible for auto-open. (try 2)
wrote: > >Since there is no neither todo_wine statements in the tests, nor test > >failures > >under Wine that means that both the tests and the patch are not OK. > > What has Wine to say when talking about the correctness > of tests? Only native dictates what the test result should be. Of course the tests are suppose to show the behaviour of Windows. > The emerging rule is: "no notification in case of error", and there's even a > specific test case about the MCI sound string command in the tests. And another rule is that the patch which changes the behaviour of an API needs to have an appropriate test case which does not pass before the patch (i.e. has the todo_wine around it), and passes after the patch (i.e. the patch removes the corresponding todo_wine). Your patch doesn't qualify for that. -- Dmitry.
RE: [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
> From: Ge van Geldorp
> > From: Roderick Colenbrander
> >
> > I'm not sure how the bot works but it looks like it concatenated some
> > of my patches together and then applied to them. I have no idea to
> > what Wine version it was since it applies fine on Wine git here. It
> > could be that I'm doing something wrong but I don't see where.
>
> No, this is the bot messing up. For some reason I don't understand yet
> it included one of your earlier patches ("[PATCH 08/13] d3d9: Add an
> initial ColorFill regression test.") as the first of this series. That
> threw everything off.
>
> I'll disable emailing to wine-devel until I've sorted this out.
Ok, I understand what happened now... This is the sequence of patches you
submitted, in the order they arrived in my mail queue (oldest first):
1) [PATCH 4/7] wined3d: Move D15S1 over to the formats table.
2) [PATCH 1/7] wined3d: Move L6V5U5 conversion to the formats table.
3) [PATCH 5/7] wined3d: Move R32G32F convertion to the formats table.
4) [PATCH 3/7] wined3d: Move D24X4S4 to the formats table.
5) [PATCH 6/7] wined3d: Move G16R16/R16G16F conversion to the formats table.
6) 1/3 d3d9: Add an initial ColorFill regression test.
7) [PATCH 2/7] wined3d: Move D24FS8 to formats table.
8) [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
Note the out-of-sequence arrival of number 6). The bot is not smart enough
to handle two series from the same author arriving interleaved. It will see
everything as one big series until all parts of a series have arrived. In
this case, the patch attached to message 6) overwrote the patch attached
to message 2) (both have part number 1).
Not sure how to handle this, except by asking people to leave some time
before sending another series.
Re-enabling emailing to wine-devel since this is working as designed.
Ge.
smime.p7s
Description: S/MIME cryptographic signature
RE: [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
> From: Roderick Colenbrander
>
> I'm not sure how the bot works but it looks like it concatenated some
> of my patches together and then applied to them. I have no idea to
> what Wine version it was since it applies fine on Wine git here. It
> could be that I'm doing something wrong but I don't see where.
No, this is the bot messing up. For some reason I don't understand yet
it included one of your earlier patches ("[PATCH 08/13] d3d9: Add an
initial ColorFill regression test.") as the first of this series. That
threw everything off.
I'll disable emailing to wine-devel until I've sorted this out.
Ge.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
I'm not sure how the bot works but it looks like it concatenated some of my patches together and then applied to them. I have no idea to what Wine version it was since it applies fine on Wine git here. It could be that I'm doing something wrong but I don't see where. Roderick On Mon, Apr 12, 2010 at 10:10 PM, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://winetestbot.geldorp.nl/JobDetails.pl?Key=1399 > > Your paranoid android. > > > === WINEBUILD (Wine build VM) === > Patch failed >
Re: [PATCH] d3dx9_36/tests: Move surface tests into surface.c (try 2)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://winetestbot.geldorp.nl/JobDetails.pl?Key=1401 Your paranoid android. === WINEBUILD (Wine build VM) === Make failed
Re: [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://winetestbot.geldorp.nl/JobDetails.pl?Key=1399 Your paranoid android. === WINEBUILD (Wine build VM) === Patch failed
winmm: MCI system commands are not eligible for auto-open. (try 2)
Dmitry Timoshkov wrote: >Since there is no neither todo_wine statements in the tests, nor test failures >under Wine that means that both the tests and the patch are not OK. What has Wine to say when talking about the correctness of tests? Only native dictates what the test result should be. The emerging rule is: "no notification in case of error", and there's even a specific test case about the MCI sound string command in the tests. I believe you forgot that AJ mentioned a notification test failure that appeared with "try 1": So there was a test failure under Wine. >> b) There was no need for todo_wine in the past because this double error >> could >>not be detected. No notification was and is the correct behaviour when >> the >>sound command returns an error, as it currently does. >Then that's what you need to fix in the first place. I cannot demonstrate the value of a fix to MCI_SOUND via a test case if the parser never calls MCI_SOUND. That's why the order in my git tree and that of submission is: 1. Get MCI_SOUND called (and fix the notification because of the test failure this introduces). 2. Get MCI_SOUND to actually play a sound (in my queue, past the 64bit patch). I find it illogical to write a patch that would prefix an existing test with todo_wine. I aim at eliminating existing todo_wine. Now I think the subject of my patch is misleading. It should have read "winmm: Correctly deal with MCI system commands." (to some extent). Regards, Jörg Höhle.
Re: winmm: MCI system commands are not eligible for auto-open. (try 2)
wrote: > >I don't see any corresponding changes in that patch that remove todo_wine > >statements > >in the tests. That suggests that either such tests don't exist, or that > >change actually > >fixes nothing. > A third explanation is possible: > It's an example of one bug shadowing another bug. > > There's no todo_wine to remove because > a) No Notification was sent in Wine because the parser did >not correctly handle system commands. MCI_Sound was never called so >there was no notification. > b) There was no need for todo_wine in the past because this double error could >not be detected. No notification was and is the correct behaviour when the >sound command returns an error, as it currently does. Then that's what you need to fix in the first place. > b) When I fixed that in "try 1", AJ observed the notification test failure. >That's why I had to fix the notification as well for "try 2". > > The tests pass on MS (in both MMSYS_NOERROR and MCIERR_HARDWARE modes) > proving they are ok. Since there is no neither todo_wine statements in the tests, nor test failures under Wine that means that both the tests and the patch are not OK. -- Dmitry.
winmm: MCI system commands are not eligible for auto-open. (try 2)
Dmitry Timoshkov wrote: >I don't see any corresponding changes in that patch that remove todo_wine >statements >in the tests. That suggests that either such tests don't exist, or that change >actually >fixes nothing. A third explanation is possible: It's an example of one bug shadowing another bug. There's no todo_wine to remove because a) No Notification was sent in Wine because the parser did not correctly handle system commands. MCI_Sound was never called so there was no notification. b) There was no need for todo_wine in the past because this double error could not be detected. No notification was and is the correct behaviour when the sound command returns an error, as it currently does. b) When I fixed that in "try 1", AJ observed the notification test failure. That's why I had to fix the notification as well for "try 2". The tests pass on MS (in both MMSYS_NOERROR and MCIERR_HARDWARE modes) proving they are ok. Regards, Jörg Höhle.
Re: winmm: MCI system commands are not eligible for auto-open. (try 2)
[cc:ing wine-devel] wrote: > this is the second time that AJ commits a patch of mine despite > a comment of yours. I think that Alexandre has commited your patch slightly in a hurry, usually he waits at least several hours unless the patch is obviously correct (which is not the case here IMO). > Should I send a subsequent patch that takes > all your comments into consideration? In my opinion your patch should be reverted until all the changes have appropriate test cases, and that patch makes the tests pass (i.e. remove existing todo_wine statements). -- Dmitry.
Re: winmm: MCI system commands are not eligible for auto-open. (try 2)
writes: > Ok. After being bitten at least once by assignment/comparison > mismatch I promised myself to use that style. I'm myself used > to read code as "if A equals 3" rather than "if 3 is the value > of A" but I'm convinced that's just a matter of getting used > to this style that is less error-prone in C. gcc prints a warning in most cases where you could make the mistake, so it's not a good enough reason to make the code harder to read. -- Alexandre Julliard julli...@winehq.org
Re: winmm: MCI system commands are not eligible for auto-open. (try 2)
wrote:
> >> +FIXME("(%04x) vkey %04X stub\n", dwFlags, lpParms->nVirtKey);
> >That change is unwanted.
> I can remove it, but why? Is supporting break keys a WONTFIX in Wine?
If that's really a problem then the first thing to do is start with some bug
reports or test cases. Adding spurious FIXME's is not an improvement.
> >Do you have a test case which shows that notofication is not sent is the
> >failure case?
> It's already in mci.c:
> test_notification(hwnd, "sound notify", err ? 0 : MCI_NOTIFY_SUCCESSFUL);
> It's how all commands I've tested to some depth so far behave.
I don't see any correspnding changes in that patch that remove todo_wine
statements
in the tests. That suggests that either such tests don't exist, or that change
actually
fixes nothing.
--
Dmitry.
winmm: MCI system commands are not eligible for auto-open. (try 2)
Dmitry Timoshkov wrote:
>> +FIXME("(%04x) vkey %04X stub\n", dwFlags, lpParms->nVirtKey);
>That change is unwanted.
I can remove it, but why? Is supporting break keys a WONTFIX in Wine?
>Do you have a test case which shows that notofication is not sent is the
>failure case?
It's already in mci.c:
test_notification(hwnd, "sound notify", err ? 0 : MCI_NOTIFY_SUCCESSFUL);
It's how all commands I've tested to some depth so far behave.
> having comparison reversed doesn't
>match the style of the surrounding code.
Ok. After being bitten at least once by assignment/comparison
mismatch I promised myself to use that style. I'm myself used
to read code as "if A equals 3" rather than "if 3 is the value
of A" but I'm convinced that's just a matter of getting used
to this style that is less error-prone in C.
Regards,
Jörg Höhle.
Re: winmm: MCI system commands are not eligible for auto-open. (try 2)
wrote:
> +FIXME("(%04x) vkey %04X stub\n", dwFlags, lpParms->nVirtKey);
That change is unwanted.
> -if (dwFlags & MCI_NOTIFY)
> - mciDriverNotify((HWND)lpParms->dwCallback, wDevID,
> -(dwRet == 0) ? MCI_NOTIFY_SUCCESSFUL :
> MCI_NOTIFY_FAILURE);
> -
> +if (MMSYSERR_NOERROR==dwRet && (dwFlags & MCI_NOTIFY))
> +mciDriverNotify((HWND)lpParms->dwCallback, wDevID,
> MCI_NOTIFY_SUCCESSFUL);
> return dwRet;
> }
>
> @@ -1903,10 +1906,9 @@ static DWORD MCI_Sound(UINT wDevID, DWORD dwFlags,
> LPMCI_SOUND_PARMSW lpParms)
> dwRet = sndPlaySoundW(lpParms->lpstrSoundName, SND_SYNC) ?
> MMSYSERR_NOERROR : MMSYSERR_ERROR;
> else
> dwRet = MMSYSERR_ERROR; /* what should be done ??? */
> -if (dwFlags & MCI_NOTIFY)
> - mciDriverNotify((HWND)lpParms->dwCallback, wDevID,
> -(dwRet == 0) ? MCI_NOTIFY_SUCCESSFUL :
> MCI_NOTIFY_FAILURE);
>
> +if (MMSYSERR_NOERROR==dwRet && (dwFlags & MCI_NOTIFY))
> +mciDriverNotify((HWND)lpParms->dwCallback, wDevID,
> MCI_NOTIFY_SUCCESSFUL);
> return dwRet;
> }
Do you have a test case which shows that notofication is not sent is the
failure case?
Also 'if (MMSYSERR_NOERROR==dwRet' misses spaces, and having comparison
reversed doesn't
match the style of the surrounding code.
--
1.5.6.3
[text/plain (2B)]
--
Dmitry.
[rfc] realtime priority patch based on rtkit
Hi all,
I decided to dig through the sample documentation for rtkit and see if I
could find a way to make it work for wine.
There's still a few things missing: hardcoded libdbus soname, no
checking if dbus is available, -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include should be added to ntdll/Makefile and
SIGXCPU should demote all threads of the application back to normal priority
The server queues an APC to the target thread that signals it should try
to acquire rt prio for it. the thread makes a request to rtkit over dbus
to say it wants realtime. This is because rtkit requires the affected
process to call dbus.
Any moral objections to this approach?
Cheers,
Maarten
>From aeace7baf8a926f162cbd96dfdb5c767b4346d26 Mon Sep 17 00:00:00 2001
From: Maarten Lankhorst
Date: Fri, 20 Nov 2009 18:14:50 +0100
Subject: [PATCH 04/17] server: Thread prio patch based on rtkit
---
dlls/ntdll/rtkit.c | 201 +++
dlls/ntdll/rtkit.h | 22 ++
dlls/ntdll/sync.c | 11 +++
server/protocol.def |7 ++
server/thread.c | 14
5 files changed, 255 insertions(+), 0 deletions(-)
create mode 100644 dlls/ntdll/rtkit.c
create mode 100644 dlls/ntdll/rtkit.h
diff --git a/dlls/ntdll/rtkit.c b/dlls/ntdll/rtkit.c
new file mode 100644
index 000..1eb8fc3
--- /dev/null
+++ b/dlls/ntdll/rtkit.c
@@ -0,0 +1,201 @@
+/*-*- Mode: C; c-basic-offset: 8 -*-*/
+
+/***
+ Copyright 2009 Lennart Poettering
+
+ Permission is hereby granted, free of charge, to any person
+ obtaining a copy of this software and associated documentation files
+ (the "Software"), to deal in the Software without restriction,
+ including without limitation the rights to use, copy, modify, merge,
+ publish, distribute, sublicense, and/or sell copies of the Software,
+ and to permit persons to whom the Software is furnished to do so,
+ subject to the following conditions:
+
+ The above copyright notice and this permission notice shall be
+ included in all copies or substantial portions of the Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ SOFTWARE.
+***/
+
+#include "config.h"
+#include "wine/port.h"
+#include "wine/library.h"
+
+#include
+#include
+#ifdef HAVE_SYS_SCHED_H
+#include
+#endif
+#include
+#include "rtkit.h"
+
+#if defined(HAVE_SETRLIMIT) && defined(__linux__)
+
+#include
+#include
+#include
+#include
+#include
+
+#ifndef RLIMIT_RTTIME
+#define RLIMIT_RTTIME 15
+#endif
+
+#define RTKIT_SERVICE_NAME "org.freedesktop.RealtimeKit1"
+#define RTKIT_OBJECT_PATH "/org/freedesktop/RealtimeKit1"
+
+#define FUNCPTR(fn) static typeof(fn) *p ##fn
+
+FUNCPTR(dbus_error_init);
+FUNCPTR(dbus_error_free);
+FUNCPTR(dbus_bus_get);
+FUNCPTR(dbus_message_new_method_call);
+FUNCPTR(dbus_message_append_args);
+FUNCPTR(dbus_connection_send_with_reply_and_block);
+FUNCPTR(dbus_message_unref);
+FUNCPTR(dbus_set_error_from_message);
+#undef FUNCPTR
+
+static int translate_error(const char *name) {
+if (strcmp(name, DBUS_ERROR_NO_MEMORY) == 0)
+return -ENOMEM;
+if (strcmp(name, DBUS_ERROR_SERVICE_UNKNOWN) == 0 ||
+strcmp(name, DBUS_ERROR_NAME_HAS_NO_OWNER) == 0)
+return -ENOENT;
+if (strcmp(name, DBUS_ERROR_ACCESS_DENIED) == 0 ||
+strcmp(name, DBUS_ERROR_AUTH_FAILED) == 0)
+return -EACCES;
+
+return -EIO;
+}
+
+static void init_dbus(void) {
+#define FUNCPTR(fn) p ##fn = wine_dlsym(libdbus, #fn, NULL, 0);
+char error[512];
+void *libdbus = wine_dlopen("libdbus-glib-1.so.2", RTLD_NOW, error,
sizeof(error));
+FUNCPTR(dbus_error_init);
+FUNCPTR(dbus_error_free);
+FUNCPTR(dbus_bus_get);
+FUNCPTR(dbus_message_new_method_call);
+FUNCPTR(dbus_message_append_args);
+FUNCPTR(dbus_connection_send_with_reply_and_block);
+FUNCPTR(dbus_message_unref);
+FUNCPTR(dbus_set_error_from_message);
+#undef FUNCPTR
+}
+
+static DBusConnection *get_dbus(void) {
+static DBusConnection *bus;
+DBusError error;
+
+if (bus)
+return bus;
+init_dbus();
+pdbus_error_init(&error);
+
+bus = pdbus_bus_get(DBUS_BUS_SYSTEM, &error);
+return bus;
+}
+
+static void set_rttime_limit(void)
+{
+struct rlimit rlimit;
+static int set;
+
+if (set)
+return;
+set = 1;
+
+rlimit.rlim_max = 6000ULL;
+rlimit.rlim_cur = rlimit.rlim_max - 1000ULL;
+setrlimit( RLIMIT_RTTIME, &rlimit );
+}
+
+int rtkit_make_realtime(pid_t thread, int priority) {
+DBusConnection *bus = get_dbus();
+DBusMessage *m = NULL, *r = NULL;
+db
Re: Re : d3dx9: Implement D3DXDeclaratorFromFVF with tests
On 12 April 2010 12:10, paulo lesgaz wrote: > What do you mean? > > I think I kept the file format. > > And what are the other things ? ;) > Sorry, but I really think these are things you should be able to figure out on your own.
Re: [PATCH 09/10] wined3d: Improve FBO support in ClearSurface.
On 12 April 2010 12:44, Roderick Colenbrander wrote:
> - context = context_acquire(This, (IWineD3DSurface *)target,
> CTXUSAGE_CLEAR);
> + if (wined3d_settings.offscreen_rendering_mode == ORM_FBO)
> + {
> + if (!surface_is_offscreen((IWineD3DSurface *)target))
> + {
> + TRACE("Surface %p is onscreen\n", target);
> +
> + context = context_acquire(This, (IWineD3DSurface *)target,
> CTXUSAGE_RESOURCELOAD);
> + ENTER_GL();
> + context_bind_fbo(context, GL_FRAMEBUFFER, NULL);
> + context_set_draw_buffer(context,
> surface_get_gl_buffer((IWineD3DSurface *)target));
> + LEAVE_GL();
> + }
> + else
> + {
> + TRACE("Surface %p is offscreen\n", target);
> +
> + context = context_acquire(This, NULL, CTXUSAGE_RESOURCELOAD);
> + ENTER_GL();
> + context_bind_fbo(context, GL_FRAMEBUFFER, &context->dst_fbo);
> + context_attach_surface_fbo(context, GL_FRAMEBUFFER, 0,
> (IWineD3DSurface *)target);
> + context_attach_depth_stencil_fbo(context, GL_FRAMEBUFFER, NULL,
> FALSE);
> + LEAVE_GL();
> + }
> + }
> + else
> + {
> + context = context_acquire(This, (IWineD3DSurface *)target,
> CTXUSAGE_CLEAR);
> + }
> +
That doesn't work of course, CTXUSAGE_CLEAR isn't there just for show.
Re: [PATCH 10/10] wined3d: Add BLT_OP_COLOR_FILL to blit_supported and use it in BltOverride.
On 12 April 2010 12:44, Roderick Colenbrander wrote:
> + if (ffp_blit.blit_supported(&myDevice->adapter->gl_info,
> BLIT_OP_COLOR_FILL,
> + NULL, 0, 0, NULL,
> + &dst_rect, This->resource.usage,
> This->resource.pool, This->resource.format_desc))
> + {
> + return ffp_blit.color_fill(myDevice, This, &dst_rect, color);
> }
>
> - return ffp_blit.color_fill(myDevice, This, &dst_rect, color);
> + return cpu_blit.color_fill(myDevice, This, &dst_rect, color);
> }
> }
>
Going through struct blit_shader means that you should also check if
cpu_blit can do that operation.
Re: [PATCH 03/10] wined3d: Move D24X4S4 to the formats table.
On 12 April 2010 12:44, Roderick Colenbrander wrote:
> {WINED3DFMT_D16_UNORM, GL_DEPTH_COMPONENT24_ARB,
> GL_DEPTH_COMPONENT24_ARB, 0,
> GL_DEPTH_COMPONENT, GL_UNSIGNED_SHORT, 0,
> WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING |
> WINED3DFMT_FLAG_FILTERING | WINED3DFMT_FLAG_DEPTH,
> - ARB_DEPTH_TEXTURE, NULL},
> + ARB_DEPTH_TEXTURE, &convert_s4x4_uint_d24_unorm},
That's wrong.
Re: wineserver: Fix French manpage
2010/4/12 Nicolas Le Cam : > Le 12 avril 2010 11:02, Frédéric Delanoy a écrit > : >> 2010/4/9 Nicolas Le Cam : >>> Le 9 avril 2010 13:30, Frédéric Delanoy a >>> écrit : 2010/4/9 Nicolas Le Cam : > Hi Frédéric, > >>+processus clients se sont terminés. Ceci évite le coût inhérent à l'arrêt > sont -> soient > >>+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >>vraisemblables. > "potentiels" or "possibles" suit better. > My understanding was that it looked first in the system path, then tried in, e.g., the home dir or other directories. I guess it looks in a hardcoded list of dirs, or sthg like that. In that sense, "possibles" does not fit IMO. "potentiels" or "vraisemblables" could both fit, but I wanted to insist on the probability for the command to be there (sthg like P[potentiels] < P[vraisemblables]). Frédéric >>> It tries PATH and BINDIR (and server/wineserver if in a build >>> directory). See >>> http://source.winehq.org/git/wine.git/?a=blob;f=libs/wine/config.c#l480 >>> So 'potentiels' or 'possibles' fit better IMHO. >> >> "Probables" may possibly fit even better (altough "potentiels" should be OK)? >> >> Frédéric >> > IMHO, "Probables" or "Vraisemblables" mean that it tries randomly some > paths and isn't at all certain to succeed, IOW it sounds really weak ; > where "Potentiels" or "Possibles" mean that if wineserver can't be > found in a fixed number of (logically computed) places, you need to > fix your system because you have a problem. I really prefer the second > option. OK for "potentiels" in that case (although "probables" seems stronger than "possibles" IMHO) Frédéric
Re: wineserver: Fix French manpage
Le 12 avril 2010 11:02, Frédéric Delanoy a écrit : > 2010/4/9 Nicolas Le Cam : >> Le 9 avril 2010 13:30, Frédéric Delanoy a écrit >> : >>> 2010/4/9 Nicolas Le Cam : Hi Frédéric, >+processus clients se sont terminés. Ceci évite le coût inhérent à l'arrêt sont -> soient >+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >vraisemblables. "potentiels" or "possibles" suit better. >>> >>> My understanding was that it looked first in the system path, then >>> tried in, e.g., the home dir or other >>> directories. >>> I guess it looks in a hardcoded list of dirs, or sthg like that. In >>> that sense, "possibles" does not fit IMO. >>> "potentiels" or "vraisemblables" could both fit, but I wanted to >>> insist on the probability for the command >>> to be there (sthg like P[potentiels] < P[vraisemblables]). >>> >>> Frédéric >>> >> It tries PATH and BINDIR (and server/wineserver if in a build >> directory). See >> http://source.winehq.org/git/wine.git/?a=blob;f=libs/wine/config.c#l480 >> So 'potentiels' or 'possibles' fit better IMHO. > > "Probables" may possibly fit even better (altough "potentiels" should be OK)? > > Frédéric > IMHO, "Probables" or "Vraisemblables" mean that it tries randomly some paths and isn't at all certain to succeed, IOW it sounds really weak ; where "Potentiels" or "Possibles" mean that if wineserver can't be found in a fixed number of (logically computed) places, you need to fix your system because you have a problem. I really prefer the second option. -- Nicolas Le Cam
Re: usbhub.sys: add stubbed usbhub.sys
Damjan Jovanovic writes: > I've hacked at this enough to get some basic USB I/O working, so now I > have a better idea of what's necessary. > > I like usbhub.sys separate from usbd.sys because: > * The service is called Usbhub in the registry, drivers might depend > on the service, and having the service load usbd.sys instead of > usbhub.sys is confusing. > * usbd.sys isn't part of the device stack in any way, it's just a > utility library used to do miscellaneous things like parse USB > descriptors. Putting I/O code in there would be confusing. > * Windows from 2000 onwards uses usbhub.sys for device stack > management and I/O. No Windows version uses usbd.sys like that. > * If we don't want dlls that export nothing, mountmgr.sys also exports > nothing, so it should be part of ntoskrnl.exe by the same logic. > * There will no more usbXXX.sys files for basic USB after usbhub.sys. > We might eventually want higher-level device class drivers > (usbstor.sys, usbprint.sys) and Microsoft-provided generic drivers > (usbscan.sys) though. > * The driver doesn't load first and load usbd.sys via an import which > creates a device stack, usbhub.sys loads first and then loads drivers > (into the same process) on-demand, as their USB devices are plugged > in. > > A *very hacked* patch is attached, if you want to see how libusb-1.0 > is used. It only works just enough for the driver to read descriptors > from the device and send a few basic I/O requests. > > I'd like to start sending real patches soon, so can I add a separate > usbhub.sys or do I have to stick with usbd.sys? And is libusb-1.0 ok? It seems to me that the device detection needs to be handled by mountmgr, you don't want a libusb polling loop. Also I don't think you want to load all of usb inside the same process, native drivers will crash, and that shouldn't take down the whole usb support. I'd say you should have one process per device or something along those lines. -- Alexandre Julliard julli...@winehq.org
Re: winetricks failed, expecting "system32" where I have "System32" and so on
On Fri, 9 Apr 2010, Austin English wrote: [...] > Why did you rename system32? Are you linking your ~/.wine/drive_c to a > real windows installation? Windows paths are case insensitive so anything in drive_c should be treated in a case-insensitive way. If winetricks does not do so, then it is buggy. -- Francois Gouget http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
Re: [PATCH] d3dx9_36/tests: Move surface tests into surface.c
The issues were existing before and thus not related to the patch. The patch is only a file renaming and the test selector changed from "texture" to "surface" to match tested functions. I will see if I can do something to fix the test failures. Christian (Marvin) a écrit : Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://winetestbot.geldorp.nl/JobDetails.pl?Key=1363 Your paranoid android. === W98SE (Windows 98 Second Edition) === No test summary line found === WNT4WSSP6 (NT4 Workstation SP6 (English, IE2)) === Failure running script in VM: Exceeded timeout limit of 300 sec === W2KPROSP4 (Windows 2000 Professional SP4) === No test summary line found === WXPPROSP3 (XP Professional SP3 (English, IE6)) === No test summary line found === W2K3R2SESP2 (Server 2003 R2 Standard Edition SP2) === No test summary line found === WVISTAADM (Windows Vista (English, IE7)) === Failure running script in VM: Exceeded timeout limit of 300 sec === W2K8SE (Server 2008 Standard Edition) === Failure running script in VM: Exceeded timeout limit of 300 sec === W7PRO (Windows 7 Professional (English, IE8)) === No test summary line found === W7PROX64 (Windows 7 Professional 64 bit) === No test summary line found === W7PROX64 (Windows 7 Professional 64 bit) === No test summary line found
Re : d3dx9: Implement D3DXDeclaratorFromFVF with tests
What do you mean? I think I kept the file format. And what are the other things ? ;) A+ David De : Henri Verbeet À : wine-devel@winehq.org Envoyé le : Lun 12 avril 2010, 11 h 52 min 15 s Objet : Re: d3dx9: Implement D3DXDeclaratorFromFVF with tests Formatting, among others.
Re: d3dx9: Implement D3DXDeclaratorFromFVF with tests
Formatting, among others.
Re: [PATCH] d3dx9_36/tests: Move surface tests into surface.c
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://winetestbot.geldorp.nl/JobDetails.pl?Key=1363 Your paranoid android. === W98SE (Windows 98 Second Edition) === No test summary line found === WNT4WSSP6 (NT4 Workstation SP6 (English, IE2)) === Failure running script in VM: Exceeded timeout limit of 300 sec === W2KPROSP4 (Windows 2000 Professional SP4) === No test summary line found === WXPPROSP3 (XP Professional SP3 (English, IE6)) === No test summary line found === W2K3R2SESP2 (Server 2003 R2 Standard Edition SP2) === No test summary line found === WVISTAADM (Windows Vista (English, IE7)) === Failure running script in VM: Exceeded timeout limit of 300 sec === W2K8SE (Server 2008 Standard Edition) === Failure running script in VM: Exceeded timeout limit of 300 sec === W7PRO (Windows 7 Professional (English, IE8)) === No test summary line found === W7PROX64 (Windows 7 Professional 64 bit) === No test summary line found === W7PROX64 (Windows 7 Professional 64 bit) === No test summary line found
Re: winetricks failed, expecting "system32" where I have "System32" and so on
Austin English wrote: On Fri, Apr 9, 2010 at 8:45 AM, Helge Hafting wrote: I just tried installing gdiplus using winetricks, on a debian testing system. This failed, as winetricks tried to copy stuff into windows/system32, where I happen to have Windows/System32. I first tried making symlinks windows->Windows and system32->System32. winetricks would run, but the app using gdiplus.dll now failed to find it. The file was in Windows/System32 as expected. So I removed my links, and used search&replace on winetricks, to replace all occurences of "windows" and "system32" with captialized versions. Then I ran winetricks again. The installation succeeded this time too, but the app could still not find the dll in System32. I finally gave up and copied the dll into the directory where the app is installed. This worked, but is problematic; it will have to be done for every app that uses this dll. Why did you rename system32? Are you linking your ~/.wine/drive_c to a real windows installation? I never renamed system32 - I don't like uppercase in filenames. I can only guess that wine did it that way itself in 2003 when I installed it. I have no real windows installation. I use wine to run the one windows program I need - a raw converter for my digital camera. Helge Hafting
Re: [Wine] updated winetricks directx-beta verb
Austin English wrote: > I've updated winetricks ... > > Get it at http://winezeug.googlecode.com/svn/trunk/winetricks Were you aware that VERSION is still set to 20100317?
Re: wineserver: Fix French manpage
2010/4/9 Nicolas Le Cam : > Le 9 avril 2010 13:30, Frédéric Delanoy a écrit : >> 2010/4/9 Nicolas Le Cam : >>> Hi Frédéric, >>> +processus clients se sont terminés. Ceci évite le coût inhérent à l'arrêt >>> sont -> soient >>> +\fIwineserver\fR dans le chemin système ou quelques autres emplacements vraisemblables. >>> "potentiels" or "possibles" suit better. >>> >> >> My understanding was that it looked first in the system path, then >> tried in, e.g., the home dir or other >> directories. >> I guess it looks in a hardcoded list of dirs, or sthg like that. In >> that sense, "possibles" does not fit IMO. >> "potentiels" or "vraisemblables" could both fit, but I wanted to >> insist on the probability for the command >> to be there (sthg like P[potentiels] < P[vraisemblables]). >> >> Frédéric >> > It tries PATH and BINDIR (and server/wineserver if in a build > directory). See > http://source.winehq.org/git/wine.git/?a=blob;f=libs/wine/config.c#l480 > So 'potentiels' or 'possibles' fit better IMHO. "Probables" may possibly fit even better (altough "potentiels" should be OK)? Frédéric
Re: tools: Add French translation of wineprefixcreate manpage
2010/4/9 Nicolas Le Cam : > Le 9 avril 2010 13:23, Frédéric Delanoy a écrit : >> Well I thought about putting it in non-infinitive form, but it didn't >> sound/feel right to me. >> >> In fact "N'affiche" would be more like a description, while >> "N'afficher" is more an action/modifier/behaviour "alterator" >> which seems the purpose of an command-line option IMHO. >> >> Frédéric >> >> On Fri, Apr 9, 2010 at 9:25 AM, Nicolas Le Cam wrote: >>> Hi Frédéric, >>> +N'afficher aucun message de statut. >>> It doesn't really matter but as you don't use infinitive form >>> elsewhere perhaps "N'affiche" could be better. >>> >>> Thanks again for your work. >>> >>> -- >>> Nicolas Le Cam >>> >> > What about 'Masque (tous) les messages de statut', that should do the trick. > Right, I'll fix that and resent when I've got time Thanks for your comments. Frédéric Delanoy
Re: [Wine] updated winetricks directx-beta verb
On Mon, Apr 12, 2010 at 1:43 AM, wrote: > Austin English wrote: > >> I've updated winetricks ... >> >> Get it at http://winezeug.googlecode.com/svn/trunk/winetricks > > Were you aware that VERSION is still set to 20100317? Yes, Dan updates that when he puts it at http://kegel.com/wine/winetricks. SVN versions are 'betas'. -- -Austin
