wine-devel January 2016

wine-devel@winehq.org

71 participants
267 discussions

Re: [PATCH 5/7] ddraw/tests: Move other SetRenderState() tests to test_set_render_state().
by Marvin 28 Jan '16

28 Jan '16

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 https://testbot.winehq.org/JobDetails.pl?Key=20024 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2301: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2301: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2301: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2301: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2485: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2632: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2632: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2632: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2632: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit ddraw7) === ddraw7.c:2254: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 6/6] d3d8/tests: Test the creation of render targets with invalid multisample settings.
by Marvin 27 Jan '16

27 Jan '16

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 https://testbot.winehq.org/JobDetails.pl?Key=20021 Your paranoid android. === w1064 (32 bit device) === device.c:2727: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2732: Test failed: The focus window is active. device.c:2740: Test failed: Got unexpected hr 0x88760869. device.c:2746: Test failed: Got unexpect screen size 800x600. device.c:2761: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2770: Test failed: Got unexpect screen size 800x600. device.c:2783: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2791: Test failed: Got unexpect width 640. device.c:2792: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 5/6] d3d8/tests: Port test_checkdevicemultisampletype() from d3d9.
by Marvin 27 Jan '16

27 Jan '16

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 https://testbot.winehq.org/JobDetails.pl?Key=20020 Your paranoid android. === w1064 (32 bit device) === device.c:2668: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2673: Test failed: The focus window is active. device.c:2681: Test failed: Got unexpected hr 0x88760869. device.c:2687: Test failed: Got unexpect screen size 800x600. device.c:2702: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2711: Test failed: Got unexpect screen size 800x600. device.c:2724: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2732: Test failed: Got unexpect width 640. device.c:2733: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 6/6] jscript: Added JSON tests.
by Marvin 27 Jan '16

27 Jan '16

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 https://testbot.winehq.org/JobDetails.pl?Key=20011 Your paranoid android. === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w1064 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found === w1064 (64 bit) === No test summary line found

1 0

Re: [PATCH 3/6] jscript: Added JSON object stub implementation.
by Marvin 27 Jan '16

27 Jan '16

1 0

Re: [PATCH] cmd: Consistently wrap lines to 75 characters.
by Francois Gouget 27 Jan '16

27 Jan '16

On Fri, 3 Jul 2015, Alex Henrie wrote: > 75 characters is the maximum length of a line before gettext breaks it, > so this convention will cause each translatable string to fit snugly > into the po files. It's also about what we were doing anyway, just not > consistently. I think this patch and particularly its justification does not make any sense. The command line tool messages were wrapped to the typical width of a terminal: 80 characters. So with this change the messages now take more lines and lose in readability for the user. So now we gettext does not wrap the messages as much in the PO files. But that's totally irrelevant and invisible to the users. It's also totally irrelevant and invisible to a translator as soon as he uses a tool like poedit or a web GUI like Pootle. So what we have here is a change made solely to make things look a bit nicer to the few developers who look at PO files, at the cost of making them slightly worse for our users. Not a good tradeoff in my book and never a good justification for a patch. > I removed Hebrew "translations" of cmd.rc that were just copies of > the English strings, There was a reason for these. Has anything changed? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.

2 5

New Wiki
by Jeremy Newman 27 Jan '16

27 Jan '16

Hey all. We've migrated our Wiki to a new backend. At this point we've ported most of the English pages over. BIG BIG thanks to Rosanne for doing this migration work. Right now, the Wiki is locked down so only approved editors can make changes. So, if you need edit access, send an email to web-admin(a)winehq.org until we have a better system for approving editors in place. The old wiki is temporarily available at http://oldwiki.winehq.org If you need some content from there. I'm sure there will be plenty of things to fix. I also want to give serious kudos to Dimi and Lattica for previously hosting the Wiki. Thanks man! -N

5 7

Re: [PATCH] ntdll: Filling in memory counters under OS X.
by Ken Thomases 27 Jan '16

27 Jan '16

Hi, Thanks for the submission. See my comments below. On Jan 27, 2016, at 10:19 AM, Snorri Sturluson <snorri.sturluson(a)ccpgames.com> wrote: > > +#ifdef __APPLE__ > +#include <mach/mach.h> > +#endif We're not totally consistent about this, but probably better to conditionalize this (and the code below) on HAVE_MACH_MACH_H instead of __APPLE__. > +#if defined(__APPLE__) > + > +void fill_VM_COUNTERS(VM_COUNTERS* pvmi) This should be "static" (in both branches of the #if). > +{ > + struct mach_task_basic_info info; > + mach_msg_type_number_t infoCount = MACH_TASK_BASIC_INFO_COUNT; > + if(task_info(mach_task_self(), MACH_TASK_BASIC_INFO, (task_info_t)&info, &infoCount) == KERN_SUCCESS) You need to conditionalize this on MACH_TASK_BASIC_INFO being defined. It is not defined in the 10.5 SDK and Wine needs to compile against that. (Well, Alexandre may have finally given up on 10.5, but it's also not in the 10.6 SDK.) If it's not defined, you can fall back to TASK_BASIC_INFO_64 / struct task_basic_info_64, although it doesn't have as much information. > + { > + pvmi->VirtualSize = info.resident_size + info.virtual_size; > + pvmi->PagefileUsage = info.virtual_size; > + pvmi->WorkingSetSize = info.resident_size; pvmi->PeakWorkingSetSize can be set from info.resident_size_max, right? The other two Peak* fields could be set based on the current info.virtual_size (possibly combined with resident_size_max), at least. You could also track the highest value seen by this code, which is not the same as the real peak but at least never decreases. You would have to be careful to do it in a thread-safe manner, probably with atomic compare-and-swap in a loop. > + } You can get PageFaultCount from TASK_EVENTS_INFO / struct task_events_info.faults. Regards, Ken

1 0

Releasing wine-1.8.1 Soon
by Michael Stefaniuc 27 Jan '16

27 Jan '16

Hello guys, now that two proper devel versions are out I plan to release wine-1.8.1 next week on Monday or Tuesday (2nd or 3rd February). A list of included and queued patches can be found on https://static-winehq.rhcloud.com/stable/ Or directly via git from https://github.com/mstefani/wine-stable . I still need to pull in two bugs marked for 1.8.x (https://bugs.winehq.org/buglist.cgi?bug_status=RESOLVED&bug_status=CLOSED&l…) If you guys know other bugs or commits that should go into 1.8.1 please let me know (set 1.8.x in bugzilla, email, irc). The rules for acceptable patches for Stable are on https://wiki.winehq.org/Stable_Rules 1.8.x bugs deferred for 1.8.2 or later: - #35187 - Jade Empire Special Edition configuration tool always resetting video settings - #39838 - Wreckfest Server: Crashes at startup, unimplemented function KERNEL32.dll.GetConsoleScreenBufferInfoEx & SetConsoleScreenBufferInfoEx Out of scope for 1.8.x: - D3D10 / D3D11 as cherry-picking single commits makes no sense. Many thanks to the people that already provided me with input on patches for Stable. bye michael

1 0

crypt32:chain test failures
by Francois Gouget 27 Jan '16

27 Jan '16

crypt32:chain has started having the following failures on the 21st on essentially all the VMs it runs on: https://test.winehq.org/data/tests/crypt32:chain.html chain.c:3875: Test failed: didn't expect CERT_TRUST_IS_NOT_VALID_FOR_USAGE, got 10 chain.c:3897: Test failed: didn't expect CERT_TRUST_IS_NOT_VALID_FOR_USAGE And yet it has not been modified recently. Based on the source it looks like these tests are running against Google's certificate. Could it be that that certificate changed recently thus breaking the tests? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

1 0

← Newer
1
2
3
4
5
6
7
8
...
27
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2016