December 2009 - Wine-Devel - list.winehq.org

Re: [PATCH] hlink/tests: Repair test to work as intended

by Andrew Eikum

On 12/31/2009 06:42 AM, Paul Vriens wrote: > On 12/29/2009 12:40 AM, Andrew Eikum wrote: >> >> Paul Vriens 'fixed' this test to ensure that two strings are not the >> same. Instead, the test should test that two strings _are_ the same, >> but I accidentally compared the wrong strings in the original version. >> --- >> dlls/hlink/tests/browse_ctx.c | 19 +++++++++++-------- >> 1 files changed, 11 insertions(+), 8 deletions(-) >> >> > Hi Andrew, > > Sorry about that. Thanks for really fixing it this time. > Not at all, it was my fault it was broken in the first place. I wouldn't have noticed if you hadn't pointed it out. Andrew

Dec. 31, 2009

Re: WineTestBot changes

by Reece Dunn

2009/12/31 Greg Geldorp <ggeldorp(a)vmware.com>: > I've completed phase 2 of the testbot: besides (32 and 64 bit) Windows executables you can now also submit patch files to the bot. The bot will apply the patch files to a clean git tree, cross-compile the test and run the test on Windows VMs. You'll also be able to download the cross-compiled test executable to test it on different Windows machines. Very cool. Awesome work. - Reece

Dec. 31, 2009

WineTestBot changes

by Greg Geldorp

I've completed phase 2 of the testbot: besides (32 and 64 bit) Windows executables you can now also submit patch files to the bot. The bot will apply the patch files to a clean git tree, cross-compile the test and run the test on Windows VMs. You'll also be able to download the cross-compiled test executable to test it on different Windows machines. Ge.

Dec. 31, 2009

Re: [1/7] avifile: Initial test data and simple test for avifil32 depends

by Paul Vriens

On 12/30/2009 03:21 AM, Julius Schwartzenberg wrote: > This patch depends on Detlef Riekenberg's patch from June 2008 and > expects it to have been applied: > http://www.winehq.org/pipermail/wine-patches/2008-June/056310.html > > It was not committed due to bug 14085: > http://bugs.winehq.org/show_bug.cgi?id=14085 Can't you just submit that initial test framework with the 3 imports (if all 3 are indeed needed)? The bug will of course not be closed but at least some of your work could be committed. -- Cheers, Paul.

Dec. 31, 2009

Re: [PATCH] hlink/tests: Repair test to work as intended

by Paul Vriens

On 12/29/2009 12:40 AM, Andrew Eikum wrote: > > Paul Vriens 'fixed' this test to ensure that two strings are not the > same. Instead, the test should test that two strings _are_ the same, > but I accidentally compared the wrong strings in the original version. > --- > dlls/hlink/tests/browse_ctx.c | 19 +++++++++++-------- > 1 files changed, 11 insertions(+), 8 deletions(-) > > Hi Andrew, Sorry about that. Thanks for really fixing it this time. -- Cheers, Paul.

Dec. 31, 2009

Re: [3/4] jscript: Fix various memory and reference count leaks.

by Rob Shearman

2009/12/30 Jacek Caban <jacek(a)codeweavers.com>: > Hi Rob, > > Thanks for your work on jscript. Unfortunately fixing Valgrind on jscript is > not going to be easy. Most of your fixes are good, except clear_global part > and "jscript: Fix a circular reference caused by object and function objects > being able to have properties that are objects and functions." patch. I've > sent a test showing that Windows doesn't do that. I've resent the memory leak patch without the clear_global part. > To fix it properly we need > to implement a garbage collector. I've designed it in the very early days of > jscript, but I never had time to implement it. That sounds like an excellent piece of work for someone interested in algorithms as opposed to the usual bug fixing. I don't think I have the time to follow through on this myself at the moment. I can see how this would work for solving the general problem of circular reference counts in jscript. However, I don't see how this helps for managing the lifetime of global objects. It seems that either the global constructors have state in which case they need to be around for as long as the script context is, while not holding a reference to the script context to avoid preventing it from dying, or they don't have any state in which case they can be constructed lazily and destroyed when the last reference is removed. Thanks, -- Rob Shearman

Dec. 31, 2009

Re: Tango Icons (Almost) Ready to Go!!

by Alexandre Julliard

Joel Holdsworth <joel(a)airwebreathe.org.uk> writes: > My final question is about what to do with my source artwork. The > artwork has been collected from a variety of sources. Some is SVGs, some > gimp .xcf.bz2s, and some plain PNGs. I guess these shouldn't go into the > wine source repo, but does anyone have any bright ideas where these > files *should* go? They'll need to be published in case the icons ever > need to be changed in any way. Ideally they would all be SVG, we already have the infrastructure for that, and for regenerating the icons from it. Though I don't know how that would work for low bit depths, it probably needs some makefile work. -- Alexandre Julliard julliard(a)winehq.org

Dec. 31, 2009

Re: [2/3] kernel32: Generate the CommonProgramFiles and ProgramFiles environment variables.

by Alexandre Julliard

Andrew Nguyen <arethusa26(a)gmail.com> writes: > Some experimentation showed that the registry values that are read do > control the CommonProgramFiles and ProgramFiles environment variables. Is there any reason to not define it like the other environment variables? Is there really an app that would change the CurrentVersion key and expect the environment variable to change? -- Alexandre Julliard julliard(a)winehq.org

Dec. 31, 2009

Re: [2/3] kernel32: Generate the CommonProgramFiles and ProgramFiles environment variables.

by Nikolay Sivov

On 12/31/2009 05:47, Andrew Nguyen wrote: > Some experimentation showed that the registry values that are read do > control the CommonProgramFiles and ProgramFiles environment variables. > --- > dlls/kernel32/process.c | 27 ++++++++++++++++++++++++++- > 1 files changed, 26 insertions(+), 1 deletions(-) > Hi, Andrew. Alexandre recently removed 16bit headers inclusion, I don't think you should revert this.

Dec. 31, 2009

Re: Acting as advisor for wcmd-uplift project?

by Dan Kegel

On Sat, Dec 26, 2009 at 11:06 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > I've been following cmd.exe topic and I was concerned about the fact, that > these tests are out of Wine tree, so I wanted to help and implemented a > simple framework. I almost didn't test it so I didn't send it before. It > caused a code duplication, I'm sorry about that. I'm attaching the patch (it > requires running tools/make_makefiles) and I will leave it for others. Hmm. make depend fails with cd: 1: can't cd to programs/cmd/tests/Makefile make[1]: *** [programs/cmd/tests/Makefile/__depend__] Error 2 I suspect there is more Makefile hackery to do, too, eventually.

Dec. 31, 2009