November 2017 - Wine-Devel - list.winehq.org

Re: [PATCH] d3dx9: Reduce rounding error in D3DXQuaternionToAxisAngle
by Henri Verbeet Nov. 9, 2017

Nov. 9, 2017

On 9 November 2017 at 16:45, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > - *pangle = 2.0f * acosf(pq->w); > + *pangle = 2.0f * acos(pq->w); /* acosf has too much rounding error */ Does that rounding error by any chance get better if you replace "acosf(x)" with "atan2f(sqrtf((1.0f - x) * (1.0f + x)), x)"?

3 3

Re: [PATCH 3/3] quartz/tests: Add test AVI and MPG files.
by Marvin Nov. 9, 2017

Nov. 9, 2017

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=34047 Your paranoid android. === w2008s64 (32 bit avisplitter) === avisplitter.c:420: Test failed: Could not create null renderer: 80040154 0b98:avisplitter: unhandled exception c0000005 at 00402884 === w2008s64 (64 bit avisplitter) === avisplitter.c:420: Test failed: Could not create null renderer: 80040154 07ec:avisplitter: unhandled exception c0000005 at 0000000000402489

1 0

Re: [PATCH] ws2_32: Divide values returned for SO_RCVBUF and SO_SNDBUF by two.
by Alexandre Julliard Nov. 8, 2017

Nov. 8, 2017

Alex Henrie <alexhenrie24(a)gmail.com> writes: > From: Sebastian Lackner <sebastian(a)fds-team.de> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > Patch from Wine Staging. It looks perfectly reasonable to me, and it > fixes a couple of tests. The right way is to store that information in the server (or in a local cache) so that it's fixed for other platforms too. This was discussed on wine-devel a while back. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] make_unicode: Update unicode collation to version 10.0.0.
by Alexandre Julliard Nov. 8, 2017

Nov. 8, 2017

Jens Reyer <jre.winesim(a)gmail.com> writes: > @@ -757,13 +757,12 @@ sub READ_SORTKEYS_FILE() > } > close $INPUT; > > - # compress the keys to 32 bit: > - # key 1 to 16 bits, key 2 to 8 bits, key 3 to 4 bits, key 4 to 1 bit > + # compress the keys to 16 bit: > + # key 1 to 8 bits, key 2 to 4 bits, key 3 to 2 bits There's no matching code change, why are you changing this comment? -- Alexandre Julliard julliard(a)winehq.org

2 1

WineConf action items
by Alexandre Julliard Nov. 8, 2017

Nov. 8, 2017

Folks, We've had many good discussions at WineConf, and decided to make a number of changes. Here are the resulting action items on my plate. I'll be working on putting these changes into place over the next days/weeks: * We'll merge the wine-devel and wine-patches mailing lists, with wine-devel becoming the single channel for both patches and discussions. * We'll be hosting vkd3d, the D3D12->Vulkan library, on winehq.org in its own git repository. * We'll create a new mailing list for AppDB maintainers. * We'll start to use more detailed git commit messages, including bug references. Jeremy volunteered to research best practices from other projects so we can come up with some standards for what the messages should look like. * We'll start building binary packages for Android. * We'll continue to assign reviewers at random from the maintainer pool for patches that don't have a specific maintainer. I was concerned that this wasn't working so well, but the general consensus was that it's worth trying some more. * Code freeze for 3.0 will start around the end of November, with a final release around the end of the year. -- Alexandre Julliard julliard(a)winehq.org

8 9

Re: [PATCH 1/4] oleaut32: Initial preparation to make marshalling compatible with x86_64.
by Sebastian Lackner Nov. 8, 2017

Nov. 8, 2017

On 05.11.2017 16:00, Marcus Meissner wrote: > From: Sebastian Lackner <sebastian(a)fds-team.de> > > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/oleaut32/tmarshal.c | 94 ++++++++++++++++++++++++++---------------------- > dlls/oleaut32/typelib.c | 8 ++--- > dlls/oleaut32/typelib.h | 2 +- > 3 files changed, 57 insertions(+), 47 deletions(-) Thanks for reviewing the patches. I don't care in this case, but please note that adding Signed-off-by for other people is still not allowed (unless this was changed in the last WineConf).

2 1

Re: [PATCH] kernel32: Fix LocaleNameToLCID can not handle zh-Hant and, zh-Hans.
by Marvin Nov. 8, 2017

Nov. 8, 2017

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=34034 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: When to mark a bug as STAGED
by KKing Nov. 8, 2017

Nov. 8, 2017

<< IMO, the real question is why dead-end hacks are being included in staging in the first place. >> IMO: If not in staging, then there should be an alternative place for such hacks or patches, ideally that the AppDb can point to. People go to the AppdDb to see if an app they want or need can run ... They'll be more impressed and potentially get involved in Wine more in some way if it helps them. You can make all sorts of usual disclaimers about not part of pure process and may break at anytime etc. Accepting such hacks (somewhere) can potentially introduce a wider developer (of varying Wine based aptitude) base to draw from. The hack could provide a basis for either progressing/converting it to non dead end approach by either mentoring the original author(s) Or providing stimulus for another to take on and submit a more acceptable patch. The hack may also allow sight of further bugs down the line in the app(s) it was intended for, which sometimes helps with tackling the original issue(s) and the solution approach. << IMO if the patch solves the bug for a user, and the patch is in staging, it should be marked STAGED. The whole point of staging is that the patches may not be up to par, but are good enough for some purpose. If Office works and it didn't before, I'd say that standard is met. >> +1 Ken.

3 3

Re: V3 msvcp100: add time_get::get function with format parameters, add missing arm exports for time_get::get functions
by Piotr Caban Nov. 7, 2017

Nov. 7, 2017

Hi, > On 7 Nov 2017, at 21:37, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > > Changes from V2: fix the msvcp100 spec for 64bit. > Changes from V1: rewrite based on updated spec file. > > The 64 bit spec entry for the functions have the same parameters count > as 32 bit spec entry > <0001-V3-msvcp100-add-time_get-get-function-with-format-pa.patch> The 64-bit spec file entries still look wrong. The entries should look like this: @ cdecl -arch=win64 ?get@?$time_get(a)DV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@std@@@std@@QEBA?AV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@2(a)V32@0AEAVios_base(a)2@AEAHPEAUtm@@PEBD4(a)Z(ptr ptr ptr ptr ptr ptr ptr ptr ptr) time_get_char_get_fmt Thanks, Piotr

1 0

Re: V2 msvcp100: add time_get::get function with format parameters, add missing arm exports for time_get::get functions
by Piotr Caban Nov. 7, 2017

Nov. 7, 2017

Hi, On 11/07/17 12:01, Vijay Kiran Kamuju wrote: > +@ cdecl -arch=win64 ?get@?$time_get(a)DV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@std@@@std@@QEBA?AV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@2(a)V32@0AEAVios_base(a)2@AEAHPEAUtm@@PEBD4(a)Z(ptr ptr ptr long ptr long ptr ptr ptr ptr ptr) time_get_char_get_fmt You have missed the win64 change in msvcp100.spec file. > +@ cdecl -arch=win64 ?get@?$time_get(a)DV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@std@@@std@@QEBA?AV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@2(a)V32@0AEAVios_base(a)2@AEAHPEAUtm@@PEBD4(a)Z(ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr) time_get_char_get_fmt The function is taking 9 ptr parameters in 64-bit case (not 11). Thanks, Piotr

2 3