October 2016 - Wine-Devel - list.winehq.org

Re: [6/6] webservices: Implement WsCall.

by Marvin

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

Oct. 26, 2016

Re: [PATCH 1/4] d2d1: Implement FillContainsPoint for rectangles

by Henri Verbeet

On 21 October 2016 at 18:40, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On Fri, Oct 21, 2016 at 7:28 PM, Andrew Eikum <aeikum(a)codeweavers.com> > wrote: >> + *contains = probe.x > geometry->u.rectangle.rect.left - tolerance && >> + probe.x < geometry->u.rectangle.rect.right + tolerance && >> + probe.y > geometry->u.rectangle.rect.top - tolerance && >> + probe.y < geometry->u.rectangle.rect.bottom + tolerance; >> + > Does it really work like that? I'd expect tolerance to be irrelevant for > paths constructed purely from lines. > So basically in general case path is approximated with lines (or enclosed > area with triangles) with given tolerance, > and then point is tested against this flattened path. While in rectangular > case it's already flat to begin with. > It would certainly be nice to have some tests for how "tolerance" is handled in general, even if those tests just end up as todo_wine. Similarly, it would be nice to have some tests for how problematic transformation matrices are handled.

Oct. 26, 2016

Product Registration Bug

by Jonathan Allen

Dear List, Do we have any movement on bug 29354? I'm trying to move to an all-Linux environment and am blocked on two (old, venerable) XP (but not MS) applications that go to sleep in the ... fixme:msi:msi_validate_product_id partial stud: template ... ... code and can't move beyond that point. Completely stuck - help! Jonathan

Oct. 25, 2016

Re: [PATCH 01/10 v2] server: Introduced iosb struct for server-side IO_STATUS_BLOCK representation and use it in irp_call.

by Sebastian Lackner

2016-10-25 13:26 GMT+02:00 Jacek Caban <jacek(a)codeweavers.com>: > On 25.10.2016 06:03, Sebastian Lackner wrote: >> On 24.10.2016 15:46, Jacek Caban wrote: >>> BTW, did you expect staging patches to be so much faster in overlapped >>> case than plain Wine? I didn't look too deeply in the code, maybe there >>> is some optimization, but that's a bit suspicious. >> Thanks, these are exactly the stats I was looking for. I'm not aware of >> any special optimizations, so not sure how Staging can be faster. >> If you used a prebuilt Staging version with compiler optimization enabled >> that could also be the reason. > > I should be more precise, sorry. In my tests I used plain Wine with > staging named pipe patches applied (some trivial conflicts needed to be > resolved AFAIR). I can try it other way if you think it would be valuable. Hm, I am not sure what causes it then. I will probably do some more investigations, but it shouldn't really block your patchset. It could also be a side effect of using a different socket type (SOCK_SEQPACKET vs SOCK_STREAM) for example. > >> BTW; I assume you are aware of it already, but your current >> implementation >> lacks handling of PIPE_NOWAIT, which is also implemented in the Staging >> patchset. > > Yes, this patchset was intended to be as small as makes sense and > PIPE_NOWAIT is not implemented in current Wine anyway. PIPE_NOWAIT > should be easy to implement on top of my patches, preferably after > patches for immediate read/write returns are in (that's one of mentioned > optimization). I expect this to be very simple then. > > Thanks for the feedback. > > Best regards, > Jacek

Oct. 25, 2016

Re: [PATCH 01/10 v2] server: Introduced iosb struct for server-side IO_STATUS_BLOCK representation and use it in irp_call.

by Jacek Caban

On 25.10.2016 06:03, Sebastian Lackner wrote: > On 24.10.2016 15:46, Jacek Caban wrote: >> BTW, did you expect staging patches to be so much faster in overlapped >> case than plain Wine? I didn't look too deeply in the code, maybe there >> is some optimization, but that's a bit suspicious. > Thanks, these are exactly the stats I was looking for. I'm not aware of > any special optimizations, so not sure how Staging can be faster. > If you used a prebuilt Staging version with compiler optimization enabled > that could also be the reason. I should be more precise, sorry. In my tests I used plain Wine with staging named pipe patches applied (some trivial conflicts needed to be resolved AFAIR). I can try it other way if you think it would be valuable. > BTW; I assume you are aware of it already, but your current > implementation > lacks handling of PIPE_NOWAIT, which is also implemented in the Staging > patchset. Yes, this patchset was intended to be as small as makes sense and PIPE_NOWAIT is not implemented in current Wine anyway. PIPE_NOWAIT should be easy to implement on top of my patches, preferably after patches for immediate read/write returns are in (that's one of mentioned optimization). I expect this to be very simple then. Thanks for the feedback. Best regards, Jacek

Oct. 25, 2016

Re: Polish translation

by Nikolay Sivov

On 24.10.2016 21:55, m4sk1n wrote: > Here is translated .po file from my GlotPress. Hope it will be used. > Hi. Thank you for your contribution. Translations should be submitted as regular patches, generated using git format-patch or similar. Also make sure to use your real name when submitting.

Oct. 25, 2016

Re: [PATCH 01/10 v2] server: Introduced iosb struct for server-side IO_STATUS_BLOCK representation and use it in irp_call.

by Sebastian Lackner

On 24.10.2016 15:46, Jacek Caban wrote: > On 20.10.2016 19:17, Sebastian Lackner wrote: >> On 19.10.2016 19:05, Jacek Caban wrote: >>> v2: Don't store async queues in a list. >>> >>> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> >>> --- >>> server/async.c | 34 +++++++++++++++++++++++++++++++++ >>> server/device.c | 58 >>> +++++++++++++++++++++++++-------------------------------- >>> server/file.h | 14 ++++++++++++++ >>> 3 files changed, 73 insertions(+), 33 deletions(-) >>> >> I'm not sure if Alexandre has already agreed to this approach, but from my >> point of view it would make sense to do some measurements. How fast is the >> proposed named pipe approach compared to alternatives (unpatched Wine, or >> the Linux-only implementation included in Wine Staging)? > > As Alexandre said, I think we should concentrate on correctness first, > but I did some benchmarking that should give us overview. That is correct, but of course there isn't just one way to implement named pipes. It might also be possible to implement it in a portable way without going through wineserver or using Linux-specific functions. It would require more complexity on the ntdll side though. In fact, having object handling in ntdll (at least as fast-path for process- local objects) is something people have been thinking about since a long time, and it probably could also be used to solve the message mode problem. Nevertheless, I have to admit that reusing the driver functions is also very elegant. ;) > Proper > measuring depends on many things and different implementations have > various weaknesses. Here are a few things to keep in mind: > > - My patchset leaves room for improvements as explained in [1]. I have > prototyped patches for those optimizations and tested both with and > without them. > > - Calls with immediate results have very different characteristics than > ones that return immediately. If we need to wait, then server round > trips either using overlapped calls or blocking select require server > round trips, for which extra data that needs to be transferred with my > patchset (if not too big), shouldn't cause significant difference. When > using my tests with large buffer, most calls should have immediate > results, so I expect it to tests worst-case scenario. > > - Current Wine implementation uses blocking socket calls for > non-overlapped pipes. This significantly affects results, so I tested > both in overlapped and non-overlapped mode (although calls themselves > are not overlapped). > > - Small buffer sizes would be interesting to test, because they cause > mode blocking and thus would show differences in such case. Sadly, > staging implementation doesn't take that into account, so results would > be meaningless. > > I used the attached test with parameters: > npbench.exe 1024 10000 100000 (for non-overlapped) > npbench.exe 1024 10000 100000 1 (for overlapped) > > Results are also attached. Proper benchmarking would require a lot more > care, but I think it shows what you asked for. This implementation is > 3.3 times slower in overlapped case, 7.4 times slower in non-overlapped > tests (3.1 and 2.5 times compared to Windows in VM). I'd say that's not > too bad. Overlapped case is even faster than I expected. > > BTW, did you expect staging patches to be so much faster in overlapped > case than plain Wine? I didn't look too deeply in the code, maybe there > is some optimization, but that's a bit suspicious. Thanks, these are exactly the stats I was looking for. I'm not aware of any special optimizations, so not sure how Staging can be faster. If you used a prebuilt Staging version with compiler optimization enabled that could also be the reason. Nevertheless, the values for "plain wine+msgmode patchset+optimizations" actually look pretty good when taking into account the wineserver roundtrip. > >> In general I like the idea, but I fear that adding significant optimizations >> afterwards will be very difficult. > > FWIW, it should be fairly easy to rebase staging patches on top of my > series. It leaves the whole previous implementation mostly untouched for > byte mode case. That, however, may not be true after further changes in > the future, esp. if we decided to use server I/O implementation for byte > mode case as well. Well, I would probably keep it for some more time in Staging, but I don't think it would make sense to merge it into the development branch. Issues are easier to debug when it behaves the same on all platforms. BTW; I assume you are aware of it already, but your current implementation lacks handling of PIPE_NOWAIT, which is also implemented in the Staging patchset. Best regards, Sebastian

Oct. 25, 2016

Re: Testing: gcc -foutline-msabi-xlogues patch

by Daniel Santos

On 10/23/2016 02:34 PM, Daniel Santos wrote: > I've found a flaw in the realignment case, so nevermind about testing > that, but the normally aligned case should still be fine. Actually, I was wrong about the flaw (it was fine), but it is now more efficient with the forced-realign case and ready for testing. Also, I accidentally did the numbers wrong on how much the .text shrunk, inflating them slightly. The current delta is 19.56% for the aligned case and 18.21% for the realigned case. repo: https://github.com/daniel-santos/gcc branch: outline-msabi-xlogues-5_4_0 Thanks, Daniel

Oct. 24, 2016

Re: [PATCH 09/10] kernel32/tests: Added more named pipe tests.

by Marvin

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=26285 Your paranoid android. === w864 (64 bit pipe) === pipe.c:2575: Test failed: FlushFileBuffers failed: 87 pipe.c:2575: Test failed: FlushFileBuffers failed: 87

Oct. 24, 2016

Re: [PATCH 01/10 v2] server: Introduced iosb struct for server-side IO_STATUS_BLOCK representation and use it in irp_call.

by Jacek Caban

On 24.10.2016 15:46, Jacek Caban wrote: > - My patchset leaves room for improvements as explained in [1]. [1] https://www.winehq.org/pipermail/wine-patches/2016-October/154803.html

Oct. 24, 2016