On Thu, Dec 9, 2010 at 10:25 PM, Nikolay Sivov wrote:
> On 12/10/2010 05:11, Austin English wrote:
>>
>> msxml:domdoc -
>> http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/wine_ae-ub1004-x64/msxml3:domdoc.html
>
> I see a crash in eglibc in another log. Is it a same failure for
On 12/10/2010 05:11, Austin English wrote:
msxml:domdoc -
http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/wine_ae-ub1004-x64/msxml3:domdoc.html
I see a crash in eglibc in another log. Is it a same failure for you?
Looking at test results today, seems my 64-bit machine only has 11
failures (compared to 6 for 32-bit):
http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/wine_ae-ub1004/version.html
http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/wine_ae-ub1004-x64/version.ht
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://testbot.winehq.org/JobDetails.pl?Key=7522
Your paranoid android.
I was looking into adding better bitmaps for the toolbar controls in
hhctrl.ocx (now that we have fancy alpha transparency support) and I wanted
to make sure that the bitmaps used matched everywhere else in Wine. Looking
into how this works currently, I noticed that keeping all the toolbar
bitmaps
Andre:
My computer is set up for 125 dpi (Large Fonts on WindowsXP). Should we be
testing for this as well? This should give different results than what is
stated here. Maybe there is a better way to test this than using a fixed value
of 39 in the ok comparision.
James McKenzie
-Origin
The remote debugger is on Mint 9 32 under WINE1.2 in a virtual
machine. VS2008 is on the host PC, Win7 64. The only command line
output is that "Trace/breakpoint trap" line, and then the program
exits.
I've filed a bug here: http://bugs.winehq.org/show_bug.cgi?id=25462
and a HowTo here: http://wik
Am 07.12.2010 22:23, schrieb Joe Dluzen:
> Hi all,
>
> I've got the Visual Studio Remote Debugger working with breakpoints,
> but not with forcing the process to pause. It immediately exits with
> "Trace/breakpoint trap." I've tried looking up the error, but it seems
> that no one has this specifi
On Thu, 2010-12-09 at 07:52 -0800, Joris Huizer wrote:
> I noticed in this patch, exactly the same lines are added in all the
> functions; wouldn't it be better to add a(n) (inline) function
> isComponentEnabled(rec,package) to reduce the repetition?
I'm not opposed to consolidating the check
Francois Gouget writes:
> I'm not happy with the situation when we skip a whole test executable.
> One issue is that in such a case we don't even extract the executable
> right now, thus making it impossible to print the subtest name. So we'd
> need a different skip line format for that case.
Hello,
I noticed in this patch, exactly the same lines are added in all the functions;
wouldn't it be better to add a(n) (inline) function
isComponentEnabled(rec,package) to reduce the repetition?
HTH,
Joris
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://testbot.winehq.org/JobDetails.pl?Key=7515
Your paranoid android.
Mike Gibson writes:
> @@ -144,8 +144,23 @@ LONGLONG WINAPI RtlLargeIntegerShiftRight( LONGLONG a,
> INT count )
> */
> LONGLONG WINAPI RtlLargeIntegerArithmeticShift( LONGLONG a, INT count )
> {
> -/* FIXME: gcc does arithmetic shift here, but it may not be true on all
> platforms */
>
Michael Stefaniuc writes:
> ---
> dlls/dsound/duplex.c | 86 ++---
> 1 files changed, 53 insertions(+), 33 deletions(-)
>
> diff --git a/dlls/dsound/duplex.c b/dlls/dsound/duplex.c
> index 4a1fbd2..2fcf64c 100644
> --- a/dlls/dsound/duplex.c
> +++ b/
14 matches
Mail list logo
