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

Re: [2/3] shlwapi: Fix swapped argument order in SHMapHandle.

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=9214 Your paranoid android. === wvistau64 (32 bit ordinal) === ordinal.c:548: Test failed: SHMapHandle failed: 6 ordinal.c:551: Test failed: SHLockShared failed: 87 ordinal.c:557: Test failed: SHUnlockShared failed: 487 === w2008s64 (32 bit ordinal) === ordinal.c:548: Test failed: SHMapHandle failed: 6 ordinal.c:551: Test failed: SHLockShared failed: 87 ordinal.c:557: Test failed: SHUnlockShared failed: 487 === wvistau64 (64 bit ordinal) === ordinal.c:548: Test failed: SHMapHandle failed: 6 ordinal.c:551: Test failed: SHLockShared failed: 87 ordinal.c:557: Test failed: SHUnlockShared failed: 487 === w2008s64 (64 bit ordinal) === ordinal.c:548: Test failed: SHMapHandle failed: 6 ordinal.c:551: Test failed: SHLockShared failed: 87 ordinal.c:557: Test failed: SHUnlockShared failed: 487

Oct. 2, 2014

Re: [1/3] shlwapi/tests: Add test for SHMapHandle.

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=9213 Your paranoid android. === wvistau64 (32 bit ordinal) === ordinal.c:549: Test failed: SHMapHandle failed: 6 ordinal.c:553: Test failed: SHLockShared failed: 87 ordinal.c:560: Test failed: SHUnlockShared failed: 487 === w2008s64 (32 bit ordinal) === ordinal.c:549: Test failed: SHMapHandle failed: 6 ordinal.c:553: Test failed: SHLockShared failed: 87 ordinal.c:560: Test failed: SHUnlockShared failed: 487 === wvistau64 (64 bit ordinal) === ordinal.c:549: Test failed: SHMapHandle failed: 6 ordinal.c:553: Test failed: SHLockShared failed: 87 ordinal.c:560: Test failed: SHUnlockShared failed: 487 === w2008s64 (64 bit ordinal) === ordinal.c:549: Test failed: SHMapHandle failed: 6 ordinal.c:553: Test failed: SHLockShared failed: 87 ordinal.c:560: Test failed: SHUnlockShared failed: 487

Oct. 2, 2014

Re: [PATCH 3/3] jscript: Added support for relational CC expressions.

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=9211 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (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 === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

Oct. 2, 2014

Re: [PATCH 2/3] jscript: Added support for '==' CC expression.

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=9210 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (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 === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

Oct. 2, 2014

Re: Wine staging tree

by Austin English

On Oct 2, 2014 5:21 PM, "Sebastian Lackner" <sebastian(a)fds-team.de> wrote: > > Hi Roderick, > > On 02.10.2014 06:59, Roderick Colenbrander wrote: > > Hi Michael, > > > > Thanks for your long email about some sort of wine 'staging' project. I > > understand what you are you trying to accomplish, but I have various > > concerns, which I will share below. > > > > The initial motivation for this project seems to be to allow users to test > > patches at an earlier stage. It may allow users to run their app sooner. > > For developers it can give their code more testing, which I agree can be > > useful. > > > > My main concern is that the quality of a lot of the patches is > > unfortunately so-so, with various lose ends and side effects various > > developers can't oversee. AJ is right to reject such patches. This can be a > > hinder for a new developers, it is not always as easy to get feedback and > > yes some mentoring for new developers can really help. > > As Michael already said in his previous mail, rejecting patches if they still contain flaws, is the right and the only way to do it. And of course having a more active mailing list would speed up the process of upstreaming stuff. Nevertheless, this has nothing to do with "new developers", we know _several_ examples of long-contributing developers (don't want to point at anyone...) who have the same impression, that just sending patches and getting it accepted _or_ useful feedback for improvements just doesn't work in most cases on wine-devel. At my opinion it mainly has to do with the interest of developers to get specific issues fixed. If there is not enough interest, then a lot of useful work might just not get enough attention, and is lost, even if it was for example actually done by a _payed_ GSoC student. Even if the implementation is _not used at all_ for the final version, it is still useful to see the ideas of other developers, or for example included testcases, to confirm tha > t the "better" implementation is also correct. Developing is a process of improving a code over and over again, and there is no way to do that in an official repository. I personally like the current approach of shared repo, and it is not really that different from all the private developer repositories, which are also included in various Wine builds (wine-multimedia, wine-csmt, ...). > > > > > Over the years there have been various projects in different forms like > > PlayOnLinux to allow users to run Wine with non-upstreamed patches. As you > > know the main concern of PlayOnLinux is that due to all the patching it is > > not vanilla Wine anymore, but a 'tainted version'. This makes us typically > > reject bug reports, because we don't know what code went in it, which can > > waste a developers time. > > We are aware of that, and thats perfectly fine (more details below). > > > > > No matter how good the intentions are to do a better job than PlayOnLinux, > > I'm skeptical. I actually went over several of the patches in the repo and > > various of them look incorrect. I understand that they may make app Z work > > and while they may not always be as evil as PlayOnLinux-style hacks, I > > still don't want them to be out in the public. In my opinion any tainted > > Wine is bad for Wine developers. Yes, user may test your new patch, but I > > expect to get a lot of issues back due to other incomplete patches with > > side effects. > > "various look incorrect" <- Isn't that exactly what we were talking about? ;) If you spotted an error immediately while taking a short look, why don't you report it to us? If you mean one of the few patches, where we're not using an optimal solution yet, feel free to suggest a better one. Not sure which patches you were looking at, but most of them are correct, and might only need minor cleanup. We wouldn't add any patches where we are aware of, that it will have negative side affects for other applications. For most patches we also spend a lot of time discussing the possible effects before we come to a conclusion, if it should be added or not. > > > > > In an ideal world there would be no need for your project, because all > > patches make it upstream quickly. I think the discussion should be more on > > how to get closer and closer to this situation. I think it should more be > > found in mentoring and providing more feedback. > > Well, feel free to provide concrete suggestions if you have a better idea how to solve that. ;) > > > > > Since Wine is an open source project, nobody forbids you from working on > > your customized Wine. Providing builds to users to try it is fine with me, > > but clearly don't mark it as the official Wine, but as you already doing by > > calling it 'wine-compholio'. > > > > What does really scare me are the Fedora Wine builds. After you said that > > they incorporate your changes, I checked the rpm and indeed it uses 150+ > > custom patches from your repo. In my opinion, distro packages need to be as > > vanilla as possible to prevent the PlayOnLinux-like bug rejection issues. > > Sometimes build system change or some minor change is needed, but such an > > amount of patches is not justified. Myself I don't have much time to work > > on Wine anymore these days, but if I got bugs from Fedora users, I would > > reject their bugs. I hope other Wine developers would really do the same, > > because the packages clearly can't be trusted. > > Please note that it was never our idea to get these patches into regular distribution packages. In case of Fedora the packager contacted us, and even proceeded after both Michael and I told him about the possible consequences, and that we personally don't recommend to do that. I will not cite anything here, as this was discussed in private mail contact, but I think the Fedora guys are totally aware that each bug report by Fedora users can get rejected without a comment. > > Recently I also opened a bug report, since I would really prefer to have a clear statement somewhere, that people shouldn't report bugs to winehq, see: > https://bugzilla.redhat.com/show_bug.cgi?id=1147271 > > > > > Overall I know the intentions are good to allow users to test new code > > sooner and allow developers to get their stuff test sooner. I'm really > > skeptical about the benefit for developers due to the tainted Wine builds. > > I think overall it may actually be more negative than positive for Wine. > > I don't think so. The question is just what is better: Having users reporting the same well-known issues over and over again (have to be identified as duplicates, also wastes time!), or probably a follow-up/regression issue which cannot be reproduced with vanilla Wine (bug reports can be easily closed, when error description doesn't match on developer machine). As you might know, the second problem already applies to a _huge_ amount of bugs, since users already use various (often unnecessary) winetricks recipes without knowing what they do, or report bugs when using PlayOnLinux or at least wine-multimedia (= _every_ Ubuntu user). Unless Wine reached a state, where it works out of the box with almost every app, there will always be a specific part of users with patched/modified versions - our approach is just a bit more combined and organized than some of the previous attempts, by reducing this to work-in-progress solutions. ;) > > If you want a solution to find out if a version contains our patches: Just ask the users on the bug tracker to run "wine --patches". > > > > > Thanks, > > Roderick > > > > Regards, > Sebastian Having "wine --version" report wine-compholio would be a welcome change, imo. Also a message to terminal a la winepulse, as Rosanne suggested.

Oct. 2, 2014

Re: [2/2] kernel32/tests: Add tests for FindFirstFileExA with FIND_FIRST_EX_CASE_SENSITIVE flag.

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=9200 Your paranoid android. === wvistau64 (32 bit file) === file.c:367: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:367: Test failed: attributes of file "testfile.xxx" are 0x0820

Oct. 2, 2014

Re: Wine staging tree

by Rosanne DiMesio

On Thu, 02 Oct 2014 16:57:24 +0200 Michael Müller <michael(a)fds-team.de> wrote: > We > may consider adding a similar warning like Pulseaudio if this is going > to be a problem. > Please do so, because it is going to be a problem. The reality is users don't always tell us they are using an unsupported build; many of them don't really know what they are using. Those of us who provide user support need a way to immediately identify your build so we can direct your users to your support channels. Asking everyone to run wine --patches (which is what we would have to do without such a warning) is unreasonable. I do realize the Fedora situation is not your fault. But IMO, it illustrates why you do need to put the warning in your build. You have no way of stopping other packagers from doing the same. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Oct. 2, 2014

Re: Wine staging tree

by Michael Müller

Am 02.10.2014 um 16:21 schrieb Rosanne DiMesio: > We shouldn't have to do that. > > Users have the right to install whatever they want on their computers, but they also have the right to be fully informed of the consequences of their decision. That single sentence on your web page is not adequate warning. We've already had one invalid bug filed by a Fedora user who clearly didn't know he was using an unsupported build. > > The winepulse driver in the Ubuntu packages includes a console message explicitly telling users it is not supported by the Wine Project, and telling them where they should report problems with it. Your build should do something similar. > > This goes beyond bugzilla. Users of patched versions of Wine also cannot file AppDB test reports or ask for help on our forum. Please make that much clearer to your users. > We always call our wine version wine-compholio so that it should be clear that it is not vanilla wine. I am also not aware of any bug reports opened by wine-compholio users (except Fedora, see below). We may consider adding a similar warning like Pulseaudio if this is going to be a problem. The only difference is Fedoras Wine build, but unlike you might think, we did not ask them to include our patches. They contacted us since they wanted to include the Silverlight patches to support Pipelight, but against our recommendation to either only include the Silverlight related patches or to provide a separate package, they decided to include them all into their main wine package. As Sebastian wrote, we already opened a bug report for this in their bug tracker. Regards, Michael

Oct. 2, 2014

Re: Wine staging tree

by Rosanne DiMesio

On Thu, 02 Oct 2014 12:51:19 +0200 Sebastian Lackner <sebastian(a)fds-team.de> wrote: > > If you want a solution to find out if a version contains our patches: Just ask the users on the bug tracker to run "wine --patches". > > > We shouldn't have to do that. Users have the right to install whatever they want on their computers, but they also have the right to be fully informed of the consequences of their decision. That single sentence on your web page is not adequate warning. We've already had one invalid bug filed by a Fedora user who clearly didn't know he was using an unsupported build. The winepulse driver in the Ubuntu packages includes a console message explicitly telling users it is not supported by the Wine Project, and telling them where they should report problems with it. Your build should do something similar. This goes beyond bugzilla. Users of patched versions of Wine also cannot file AppDB test reports or ask for help on our forum. Please make that much clearer to your users. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Oct. 2, 2014

Re: [PATCH] jscript: Ignore BOM mark in next_token. (try 5)

by Qian Hong

Hi Nikolay, Thanks for commenting, your thought is helpful as usual :) I added tests for more space separators, also added tests for parseFloat(): https://testbot.winehq.org/JobDetails.pl?Key=9203&log_206=1#k206 The test result show that, older version of jscript doesn't flow the standard, while newer version is much better. The test result also show that, BOM and other space separators are also ignored in functions like parseFloat. I'm planing on adding tests for the following group of functions. parseInt() eval() isNaN() isFinite() new Number() new Function() new Date() Date.parse() RegExp() My idea is fixing the code in lex.c first, then fixing other place using isspaceW in an incremental way with tests provided, like the attached patches demos. Currently there are two troubles bothering me: 1. We need a good way to skip space tests on older IEs 2. We need a good way to reduce the length of WCHAR array for the jscript code, I believe most of us hate a long array like below... {'v','a','r',' ','a',' ','=',' ','p','a','r','s','e','F','l','o','a','t','(','"',SPACE_HOLDER,'3','.','1','4',SPACE_HOLDER,'"',')',';','o','k','(','a','=','=','3','.','1','4',',',' ','"','h','a','h','a','"',')',';','r','e','p','o','r','t','S','u','c','c','e','s','s','(',')',';','\0'} Do you have any advice? Thanks!

Oct. 2, 2014