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

Re: msi: Implement the DROP TABLE sql command.

by Rob Shearman

2008/10/2 Steven Edwards <winehacker(a)gmail.com>: > On Thu, Oct 2, 2008 at 3:25 PM, James Hawkins <jhawkins(a)codeweavers.com> wrote: >> Hi, I can't repro this problem on my machine, so I'm sending this >> patch to patchwatcher by way of wine-patches to get some info. Please >> do not apply. > > Regarding our wineconf discussion about patchwatcher spam on > wine-patches and filtering. Perhaps we need 2 email address patches > can be sent to. My thinking is the flow could be something like: > > 1. By default everyone sends a patch to wine-patches > 2. If a patch gets rejected the author gets a failure mail in private, > and now retries or testing patches should go to wine-patches-testing N > times until they get it right > 3. once its right, patchwatch could then forward the new good patch to > wine-patches or could send an email to the dev saying that its good > enough to now send to wine-patches. > > Doing it like this, if everyone follows the rules, we won't get a ton > of patchwatcher retries filling up wine-patches. I don't like this idea because of the expression "If you gave an infinite number of monkeys an infinite number of typewriters they would eventually produce the complete works of Shakespeare." In other words, if someone were to just send patches all day to patchwatcher, changing one thing at a time until they passed then one would eventually get through. However, the result in this case would probably not be a quality patch since patchwatcher would not be able to catch all possible bugs. We want to be able to track how many retries a patch has had to go through before getting through since the more it had the more bugs it is likely to have. Therefore, we want all patchwatcher failures to go to a separate mailing list where we can see if a patch is being sent repeatedly so that we can email them to say "hey, you may want to take a while to rethink this patch or ask for help on wine-devel". James, please note that I'm not accusing you of being one of said monkeys, I realise this is an exception :-) -- Rob Shearman

Oct. 2, 2008

Re: msi: Implement the DROP TABLE sql command.

by Austin English

On Thu, Oct 2, 2008 at 3:47 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > On Thu, Oct 2, 2008 at 4:42 PM, Austin English <austinenglish(a)gmail.com> wrote: >> You'd still be sending the patch twice to wine-patches, and by that >> logic, for _EVERY_ patch, not just ones that were rejected. > > No. you would only have to send it again if the first one was rejected > by patchwatcher. By default no ones work flow would change, just the > email you are sending it to for retries saving everyones inbox on > spam. If your patch was bad you would still have to do extra leg work > but all of that would be done in private. If we get make test working > in more places then its possible the number of first time failures to > wine-patches will go down also if we can encourage people to run make > test before submitting patches. > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > Here's how I understand your idea, correct me if I'm wrong: WinedevA submits a patch to wine-patches. Crashes on patchwatcher, etc. WinedevA gets a private e-mail from patchwatcher saying "you're a failure, learn to code better, fix this, etc.". WinedevA fixes patch up, resubmits to wine-patches-testing multiple times, finally gets it right. He does a little dance, celebrates, etc. Patchwatcher then forwards this good patch to wine-patches. WinedevB submits a patch to wine-patches, works fine. Passes patchwatcher, no valgrind warnings, etc. Because it passed, it then forwards it to wine-patches. Unless patchwatcher somehow keeps track of all patches that have failed and been resubmitted, which seems like extra work for nothing. I thought we had a consensus on the process I mentioned earlier... -Austin

Oct. 2, 2008

Re: msi: Implement the DROP TABLE sql command.

by Steven Edwards

On Thu, Oct 2, 2008 at 4:42 PM, Austin English <austinenglish(a)gmail.com> wrote: > You'd still be sending the patch twice to wine-patches, and by that > logic, for _EVERY_ patch, not just ones that were rejected. No. you would only have to send it again if the first one was rejected by patchwatcher. By default no ones work flow would change, just the email you are sending it to for retries saving everyones inbox on spam. If your patch was bad you would still have to do extra leg work but all of that would be done in private. If we get make test working in more places then its possible the number of first time failures to wine-patches will go down also if we can encourage people to run make test before submitting patches. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Oct. 2, 2008

Re: msi: Implement the DROP TABLE sql command.

by Austin English

On Thu, Oct 2, 2008 at 3:27 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > On Thu, Oct 2, 2008 at 3:25 PM, James Hawkins <jhawkins(a)codeweavers.com> wrote: >> Hi, I can't repro this problem on my machine, so I'm sending this >> patch to patchwatcher by way of wine-patches to get some info. Please >> do not apply. > > Regarding our wineconf discussion about patchwatcher spam on > wine-patches and filtering. Perhaps we need 2 email address patches > can be sent to. My thinking is the flow could be something like: > > 1. By default everyone sends a patch to wine-patches > 2. If a patch gets rejected the author gets a failure mail in private, > and now retries or testing patches should go to wine-patches-testing N > times until they get it right > 3. once its right, patchwatch could then forward the new good patch to > wine-patches or could send an email to the dev saying that its good > enough to now send to wine-patches. You'd still be sending the patch twice to wine-patches, and by that logic, for _EVERY_ patch, not just ones that were rejected. I think the idea at Wineconf was the best: Submit patches to wine-patches Patchwatcher does its voodoo magic If patch is good -> wine-patches-approved If patch fails -> wine-patches-rejected + e-mail to author However, I think your idea has merit...if Dan would be willing, could add a test e-mail, that doesn't spam everyone, for testing only on patchwater. I.e., patch-test(a)kegel.com. Results would then join the rest on the results page (or possibly just e-mailed back, but that seems like more work for little gain. -Austin

Oct. 2, 2008

Re: msi: Implement the DROP TABLE sql command.

by James Hawkins

On Thu, Oct 2, 2008 at 3:27 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > On Thu, Oct 2, 2008 at 3:25 PM, James Hawkins <jhawkins(a)codeweavers.com> wrote: >> Hi, I can't repro this problem on my machine, so I'm sending this >> patch to patchwatcher by way of wine-patches to get some info. Please >> do not apply. > > Regarding our wineconf discussion about patchwatcher spam on > wine-patches and filtering. Perhaps we need 2 email address patches > can be sent to. My thinking is the flow could be something like: > > 1. By default everyone sends a patch to wine-patches > 2. If a patch gets rejected the author gets a failure mail in private, > and now retries or testing patches should go to wine-patches-testing N > times until they get it right > 3. once its right, patchwatch could then forward the new good patch to > wine-patches or could send an email to the dev saying that its good > enough to now send to wine-patches. > > Doing it like this, if everyone follows the rules, we won't get a ton > of patchwatcher retries filling up wine-patches. > Just so everyone is clear, I emailed Dan before submitting the patches asking if there was a way to send a patch directly to patchwatcher and bypass wine-patches, but he said there's not a way yet and that sending the patch to wine-patches should be OK for now. -- James Hawkins

Oct. 2, 2008

Re: howto fix bug 13462

by Louis Lenders

Rob Shearman <robertshearman <at> gmail.com> writes: Thanks very much for your comments Rob, I've updated the patch here: http://bugs.winehq.org/attachment.cgi?id=16397 Hopefully correct now? But now got another problem with the test, i changed it a bit like here: http://bugs.winehq.org/attachment.cgi?id=16430 This test passes fine in Xp, but not in wine, more specific, this part fails: pCoInitializeEx(NULL, COINIT_APARTMENTTHREADED); . . . . if(hr == S_OK) refs = IContextCallback_Release(pComThreadingInfo); ok(refs == 0, "pComThreadingInfo should have 0 refs instead of %d refs\n", refs); In windows it shows the refcount should be zero in the end, but with my patch and this test, it doesn't (refcount =2 in the end). I added several traces to the code to show how the refcount was in/decreased, but wasn't able to figure out what goes wrong, it's quite mysterious. Whereas this test fails, the one that starts with pCoInitializeEx(NULL, COINIT_MULTITHREADED) passes just fine in wine. Am i still missing something?

Oct. 2, 2008

Re: msi: Implement the DROP TABLE sql command.

by Steven Edwards

On Thu, Oct 2, 2008 at 3:25 PM, James Hawkins <jhawkins(a)codeweavers.com> wrote: > Hi, I can't repro this problem on my machine, so I'm sending this > patch to patchwatcher by way of wine-patches to get some info. Please > do not apply. Regarding our wineconf discussion about patchwatcher spam on wine-patches and filtering. Perhaps we need 2 email address patches can be sent to. My thinking is the flow could be something like: 1. By default everyone sends a patch to wine-patches 2. If a patch gets rejected the author gets a failure mail in private, and now retries or testing patches should go to wine-patches-testing N times until they get it right 3. once its right, patchwatch could then forward the new good patch to wine-patches or could send an email to the dev saying that its good enough to now send to wine-patches. Doing it like this, if everyone follows the rules, we won't get a ton of patchwatcher retries filling up wine-patches. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Oct. 2, 2008

Re: [PATCH 4/4] jscript: Added possibility to run test scripts from file.

by winepatches＠kegel.com

> > With this patch it's possible to test scripts by running > wine jscript_test.exe.so run <file_name> > Although it's not what Wine tests are for, it proved to be very useful > for me. That's the second time in the last couple days that your patches confused patchwatcher's patch series detector. You resent patch 4/4 from a different series, and patchwatcher took that other 4/4 and used it in place of this one, leaving this patch as a stuck singleton. Tips: 1) never send two series of the same length on the same day (This confuses even humans.) 2) never partially resend patch series, always resend the whole series. (Eventually patchwatcher will handle this better.)

Oct. 2, 2008

Re: Detecting Wine

by Scott Ritchie

Markus Hitter wrote: > Am 30.09.2008 um 12:55 schrieb Eric Pouech: > >> Your design is wrong IMO. You don't handle reparse points at all; >> you only >> rely on the nature of a drive, which isn't sufficient in most >> cases. See >> mounting volumes for example where you can mount a whole volume >> anywhere in >> an NTFS partition. >> >> The correct fix would be to: >> - ensure your code handles those cases correctly (which it doesn't) >> - ensure that wine returns the correct relevant information for remote >> mounted FS (which I'm pretty sure sure it's not done today) > > A reasonable 99% shortcut would probably be to parse C: only. This > should be sufficient for almost all users, especially the clueless > ones, on Wine as well as on Windows. > > > MarKus As long as the scan can be canceled, that should cover just about every use case. Clueless users let it work, clueful users know to cancel it because it's looping with their reparse points in C:\ and never getting to D:\ Thanks, Scott Ritchie

Oct. 2, 2008

Re: Be careful out there

by Roderick Colenbrander

The names in the headers don't matter to programs which use them and source which is compiled using them. Only the order matters. Using the same names is fine. Roderick > Andrew Fenn wrote: > > Actually I wanted to ask a question about this.. > > > > When implementing an API do we have to change the variable names from > > those given in the msdn documentation? > > > > More specifically, the typedefs for the xinput structs ( documentation > > here: http://msdn.microsoft.com/en-us/library/bb173049(VS.85).aspx ). > > Do I have the change the names of these or can I just keep them the > > same? > > If you change these name your implementation will only be binary > compatible but source code has to be modified to work with your headers. > So you should use the same names in header files. > > Kornél > -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Oct. 2, 2008