September 2011 - Wine-Devel

Re: Buildbot status

by Octavian Voicu

On Thu, Sep 29, 2011 at 12:59 PM, Dan Kegel <dank(a)kegel.com> wrote: > Do you object to Greg's existing testbot emails, too? They're annoying when they are spurious... Octavian

Sept. 29, 2011

[PATCH 0/5] CMD command line parsing (try 5)

by Martin Wilck

Contrary to what I said before, here is another attempt for my CMD patch series. Thanks to Frederic for reviewing this again, I made the suggested changes. Martin Wilck (5): cmd/tests: add tests for command line parsing cmd: use GetCommandline() rather than argv cmd: improve parsing of quotes in command line cmd: fix handling of special characters in command line cmd: fix parameter parsing of quotes and special chars programs/cmd/batch.c | 83 ++++++--- programs/cmd/tests/rsrc.rc | 6 + programs/cmd/tests/test_builtins.cmd.exp | 8 +- programs/cmd/tests/test_cmdline.cmd | 158 +++++++++++++++++ programs/cmd/tests/test_cmdline.cmd.exp | 77 +++++++++ programs/cmd/wcmdmain.c | 276 ++++++++++++------------------ 6 files changed, 407 insertions(+), 201 deletions(-) create mode 100644 programs/cmd/tests/test_cmdline.cmd create mode 100644 programs/cmd/tests/test_cmdline.cmd.exp -- 1.7.3.4

Sept. 29, 2011

Re: [PATCH 0/5] (4th attempt) CMD command line parsing

by Martin Wilck

>> This will also be my last attempt to get this merged. > > Saying this is the best way to ensure that they won't be merged. Why > would people spend time reviewing your code if you've already decided > that you are not going to address the issues they find? I also said that I'd address issues with my code, and I will. Anyway, I was lucky that Dan and Frédéric did review my code again, and so I'll take another shot, contrary to what I said before. Regards Martin

Sept. 29, 2011

Re: Buildbot status

by Dan Kegel

Do you object to Greg's existing testbot emails, too? Well before I flip the switch to turn on email to wine-devel, I will have a nice history of those emails for viewing, so people can judge the actual added noise level for themselves. On Thu, Sep 29, 2011 at 12:20 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > How about just sending error emails to the wine-bots list, AJ and the > patch author? To be really honest I hate reading all the testbot > emails on wine-devel. > > J > > On Thu, Sep 29, 2011 at 7:43 PM, Dan Kegel <dank(a)kegel.com> wrote: >> The buildbot is alive and well and has been finding real >> problems of various sorts roughly once a day for some time. >> I'm not spending much time on it anymore, just watching >> and tweaking occasionally. >> >> The number of spurious failures is tapering off as I >> slowly expand the blacklist and polish up the scripts. >> I plan to turn on email notifications to wine-devel once >> there have been no spurious failure reports for five days, >> probably sometime in October. >> >> http://wiki.winehq.org/BuildBot is up to date in case >> anyone's interested in details. >> >> >> >

Sept. 29, 2011

Re: Buildbot status

by Jerome Leclanche

How about just sending error emails to the wine-bots list, AJ and the patch author? To be really honest I hate reading all the testbot emails on wine-devel. J On Thu, Sep 29, 2011 at 7:43 PM, Dan Kegel <dank(a)kegel.com> wrote: > The buildbot is alive and well and has been finding real > problems of various sorts roughly once a day for some time. > I'm not spending much time on it anymore, just watching > and tweaking occasionally. > > The number of spurious failures is tapering off as I > slowly expand the blacklist and polish up the scripts. > I plan to turn on email notifications to wine-devel once > there have been no spurious failure reports for five days, > probably sometime in October. > > http://wiki.winehq.org/BuildBot is up to date in case > anyone's interested in details. > > >

Sept. 29, 2011

Buildbot status

by Dan Kegel

The buildbot is alive and well and has been finding real problems of various sorts roughly once a day for some time. I'm not spending much time on it anymore, just watching and tweaking occasionally. The number of spurious failures is tapering off as I slowly expand the blacklist and polish up the scripts. I plan to turn on email notifications to wine-devel once there have been no spurious failure reports for five days, probably sometime in October. http://wiki.winehq.org/BuildBot is up to date in case anyone's interested in details.

Sept. 29, 2011

Re: [PATCH] winex11: Make MapColor fall back to GetNearestIndex

by Alex Henrie

2011/9/29 David Kiefer <hevanen(a)googlemail.com>: > A possible solution is to have MapColor call GetNearestIndex as a last > resort instead. This both fixes the problem and results in acceptable > performance. Thanks for the tip. I've submitted a new patch which uses this solution instead, and it works better. 2011/9/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > I'm not really sure how useful it is to try to optimize parts of the > X11 code now that the DIB engine is progressing nicely. Once the DIB > engine is done this code will disappear anyway. No need for horrible > X11 hacks to offload any DIB rendering and converting the X11 result > back into a DIB. You're right: the DIB engine would be much better. What needs to be done to get the DIB engine to work with Age of Empires II? -Alex

Sept. 29, 2011

Re: [PATCH] Enable X11DRV_DIB_GetImageBits_8 in all cases and optimize X11DRV_DIB_GetNearestIndex to fix bug 2666 and other strange behavior

by Roderick Colenbrander

On Thu, Sep 29, 2011 at 12:57 PM, David Kiefer <hevanen(a)googlemail.com> wrote: > While this patch indeed fixes bug 2666, it also kills performance, at > least with Age of Empires II. > The frame rate in the menu for me is about one frame every three seconds > and about 1 fps in-game. > > With the patch, the work previously done by X11DRV_DIB_MapColor is now > done by X11DRV_DIB_GetNearestIndex. Unlike GetNearestIndex, MapColor > avoids traversing the entire palette most of the time by reusing the > previous index in the destination bitmap if the color has not changed. > However, MapColor only checks for exact matches and returns the first > palette entry if none was found, effectively causing bug 2666. > A possible solution is to have MapColor call GetNearestIndex as a last > resort instead. This both fixes the problem and results in acceptable > performance. > > David > > > I'm not really sure how useful it is to try to optimize parts of the X11 code now that the DIB engine is progressing nicely. Once the DIB engine is done this code will disappear anyway. No need for horrible X11 hacks to offload any DIB rendering and converting the X11 result back into a DIB. Roderick

Sept. 29, 2011

Odd audio regression (interaction between two commits)

by Erich Hoover

A: 64b14c0ecdd13530a92ff636c451523a99253a0b (quartz: Start DirectSound renderer as soon as possible.) B: e786998daff4ad49521a4c9c39c172ddcdcad82a (dsound: Reimplement rendering devices on mmdevapi.) I've been working with the audio in Fallout 3 and Fallout New Vegas for some time and I noticed a regression recently where the audio stopped working properly after the main menu (commit B). This triggered a memory of a similar experience I had where commit A caused the same behavior, but it only did so for PulseAudio users. So, on a hunch, I reverted commit A on the latest git and found that the audio went back to normal again. I'm not entirely sure what commit A could do to cause this problem, and I know you guys are busy with the audio changes, so if someone could point me in the right direction then I will try and track this issue down. Thanks! Erich Hoover ehoover(a)mines.edu

Sept. 29, 2011

Re: winecfg: Remove driver selection from Audio tab.

by Alex Bradbury

On 29 September 2011 15:03, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > I can think of few things can be implemented right away and see how it goes: A lot of these seem like a great way to slow wine development down. Honestly I think better investment in automated application testing would be more helpful to the project (I'm just an outside observer of course). I know cxtest didn't really work out, but Scott Ritchie has talked of some very straight-forward scripted testing of apps available in winetricks which seems sensible. Additionally, you could imagine checking a large library of game demos that 1) they don't crash 2) some sort of sound output is produced. It's a weak test, but it could be easily automated. > 1. Longer release cycle. Lets start with 3-4 weeks and extend if needed. > Allow any new features first week of the release cycle only. Next two weeks > are bug fixes and stabilization before release. > > Or have same 2 week release cycle with every other release being release > candidate and code freeze for the second 2 weeks to stabilize it. This is actually not a bad idea. I think that currently changes which are likely to break things mostly end up in the first week of the two week cycle, but then not many users test (with some notable exceptions, like GyB the one-person regression-hunting machine). 1.3.odd releases having larger changes with more likelihood of breakage than 1.3.even releases (hopefully fixing any reported issues) does sound worth considering. > 3. All regressions should be treated as blockers. And fixed before next > release. If a regression is in some other area then patch introducing > regression, no patches should be accepted from anyone else to the area in > question until this regression is fixed. Or a work around found. People complaining about the difficulty of getting a patch in to wine already seems to be an issue. This all sounds a little arbitrary to me. I do subscribe to wine-bugs and it seems to me that most bisected regressions get addressed promptly. Alex

Sept. 29, 2011