On 11/10/06, Robert Reif <[EMAIL PROTECTED]> wrote:
This patch
http://www.winehq.org/pipermail/wine-cvs/2006-November/027732.html
breaks http://angusj.com/sudoku/
I tested it thoroughly and it looks perfect to me both with and
without the patch.
What exactly is wrong and how do you reproduce
As glibc manual
http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library.html
says:
QUOTE
When you read the current locale for category LC_ALL, the value encodes the
entire combination of selected locales for all categories. In this case, the
value is not just a single locale name. In
Hi, all!
The following patch:
http://www.winehq.org/pipermail/wine-cvs/2006-November/027599.html
breaks locale with wine.
I get several messages:
Warning: Language 'LC_CTYPE=ru_RU' was not recognized, defaulting to English.
Warning: Language 'LC_CTYPE=ru_RU' was not recognized, defaulting to Eng
Am Freitag 10 November 2006 10:23 schrieb Mirek:
> Hi i have found Nvidia SDK programs and demos, i can install it in wine
> and some D3D demos can even run, but almost all are someway broken, in
> Nvidia SDK there are even source codes for those demos, what about start
> improving Direct3D in wine
Alexandre Julliard wrote:
Eric Pouech <[EMAIL PROTECTED]> writes:
reading from wine/list.h
#define LIST_FOR_EACH_SAFE(cursor, cursor2, list) \
for ((cursor) = (list)->next, (cursor2) = (cursor)->next; \
(cursor) != (list); \
(cursor) = (cursor2), (cursor2) = (cursor)->next)
On 11/10/06, Robert Reif <[EMAIL PROTECTED]> wrote:
This patch
http://www.winehq.org/pipermail/wine-cvs/2006-November/027732.html
breaks http://angusj.com/sudoku/
Thanks, I'll test it this weekend.
Damjan
Eric Pouech <[EMAIL PROTECTED]> writes:
> reading from wine/list.h
> #define LIST_FOR_EACH_SAFE(cursor, cursor2, list) \
>for ((cursor) = (list)->next, (cursor2) = (cursor)->next; \
> (cursor) != (list); \
> (cursor) = (cursor2), (cursor2) = (cursor)->next)
>
> well, to me, the
- the generic issue in the SAFE version, where we still access the
cursor after it has been potentially fixed
No, in the SAFE macros we don't, that's the whole point of having
them.
reading from wine/list.h
#define LIST_FOR_EACH_SAFE(cursor, cursor2, list) \
for ((cursor) = (list)
This patch
http://www.winehq.org/pipermail/wine-cvs/2006-November/027732.html
breaks http://angusj.com/sudoku/
Eric Pouech <[EMAIL PROTECTED]> writes:
> I've seen it too, but it was only for current cursor not next, which
> still means we have :
> - the issue in process termination, where an iteration in the loop can
> kill more than one item in the list
This is fixed now.
> - the generic issue in the
Mike McCormack wrote:
Eric Pouech wrote:
well, the kill_thread in that case in only done when the waiting
thread also died while waiting (ie has been killed by some other way)
(in normal cases, the wait operation on the waiting side would just
return an error code)
the I'm not still convic
Hi!
The following patch:
http://www.winehq.org/pipermail/wine-cvs/2006-September/025991.html
[
106156cb7597cf6f077b6f4e9d7562d8932fd766 is first bad commit
commit 106156cb7597cf6f077b6f4e9d7562d8932fd766
Author: Robert Shearman <[EMAIL PROTECTED]>
Date: Mon Sep 11 11:14:25 2006 +0100
ole
Eric Pouech wrote:
well, the kill_thread in that case in only done when the waiting thread
also died while waiting (ie has been killed by some other way) (in
normal cases, the wait operation on the waiting side would just return
an error code)
the I'm not still conviced this path is actually
2006/11/10, Mike McCormack <[EMAIL PROTECTED]>:
Eric Pouech wrote:> IIRC, the issue in this code is that you access in _SAFE macro the next
> field in the current cursor *after* the current cursor has been freed> the issue is not that the next item has been freed while itering on the> current curs
Mirek wrote:
This patch broke nvidia SDK opengl demos, i cant run it with this patch.
Here is some small report from terminal:
cvswine glsl_bump_mapping.exe
err:wgl:process_attach X11DRV or GDI32 not loaded. Cannot create
default context.
err:module:LdrInitializeThunk "opengl32.dll" failed to i
Eric Pouech wrote:
IIRC, the issue in this code is that you access in _SAFE macro the next
field in the current cursor *after* the current cursor has been freed
the issue is not that the next item has been freed while itering on the
current cursor
(this was at least the issue I had)
It looks
Hi i have found Nvidia SDK programs and demos, i can install it in wine
and some D3D demos can even run, but almost all are someway broken, in
Nvidia SDK there are even source codes for those demos, what about start
improving Direct3D in wine with help of this demos? It should be easy to
track
IIRC, the issue in this code is that you access in _SAFE macro the next field in the current cursor *after* the current cursor has been freed
the issue is not that the next item has been freed while itering on the current cursor
(this was at least the issue I had)
so the first is to set the next cu
Eric Pouech wrote:
IMO this should be fixed by rewriting correctly the _SAFE version of the
list macros, which are to blame here.
I have this somewhere, I'll send it later on.
The only way to prevent the next pointer (or any other pointer in the
thread list) from being free'd is to grab it.
IMO this should be fixed by rewriting correctly the _SAFE version of the list macros, which are to blame here.
I have this somewhere, I'll send it later on.
2006/11/10, Mike McCormack <[EMAIL PROTECTED]>:
---server/process.c | 28 1 files changed, 24 insertions(+), 4 d
On Wed, Nov 08, 2006 at 10:32:05PM +0100, Mirek wrote:
> Here is some small report from terminal:
> cvswine glsl_bump_mapping.exe
> err:wgl:process_attach X11DRV or GDI32 not loaded. Cannot create default
> context.
> err:module:LdrInitializeThunk "opengl32.dll" failed to initialize, aborting
> e
21 matches
Mail list logo
