Re: gdiplus: fix font test when liberation fonts are installed
Austin English wrote: > >> +ok(!lstrcmp(lf.lfFaceName, "Arial") || > >> + !lstrcmp(lf.lfFaceName, "Liberation Sans"), "wrong face name > >> %s\n", lf.lfFaceName); > > > > The tests are supposed to reflect Windows behaviour, what Windows version > > does return "Liberation Sans" in this test? > > Obviously none, though it seems to a reasonable adjustment, since the > Liberation team can't use the Arial name. We already do something > similar in dlls/gdi32/freetype.c for liberation mono/sans/serif fonts. Just consider a failing test as a sign that something is broken in the tested invironment, and some real world application will fail as well (otherwise the test doesn't make sense). The environment should be fixed instead of adjusting the test. -- Dmitry.
Re: gdiplus: fix font test when liberation fonts are installed
On Wed, Oct 17, 2012 at 7:54 PM, Dmitry Timoshkov wrote: > Austin English wrote: > >> +ok(!lstrcmp(lf.lfFaceName, "Arial") || >> + !lstrcmp(lf.lfFaceName, "Liberation Sans"), "wrong face name %s\n", >> lf.lfFaceName); > > The tests are supposed to reflect Windows behaviour, what Windows version > does return "Liberation Sans" in this test? Obviously none, though it seems to a reasonable adjustment, since the Liberation team can't use the Arial name. We already do something similar in dlls/gdi32/freetype.c for liberation mono/sans/serif fonts. -- -Austin
Re: gdiplus: fix font test when liberation fonts are installed
Austin English wrote: > +ok(!lstrcmp(lf.lfFaceName, "Arial") || > + !lstrcmp(lf.lfFaceName, "Liberation Sans"), "wrong face name %s\n", > lf.lfFaceName); The tests are supposed to reflect Windows behaviour, what Windows version does return "Liberation Sans" in this test? -- Dmitry.
Re: Ubuntu 12.10 - anyone?
I just upgraded to 12.04, until they fix the "32-bit headers problem" you'll have to manually create the symbolic links for the "-dev" package behavior: cd /usr/lib/i386-linux-gnu sudo ln -s libfreetype.so.6 libfreetype.so sudo ln -s libXau.so.6 libXau.so sudo ln -s libXcursor.so.1 libXcursor.so sudo ln -s libXi.so.6 libXi.so sudo ln -s libXext.so.6 libXext.so sudo ln -s libXxf86vm.so.1 libXxf86vm.so sudo ln -s libXrandr.so.2 libXrandr.so sudo ln -s libXrender.so.1 libXrender.so sudo ln -s libXinerama.so.1 libXinerama.so sudo ln -s libXcomposite.so.1 libXcomposite.so sudo ln -s libGLU.so.1 libGLU.so sudo ln -s libOSMesa.so.6 libOSMesa.so sudo ln -s libgnutls.so.26 libgnutls.so sudo ln -s libsane.so.1 libsane.so sudo ln -s libv4l1.so.0 libv4l1.so sudo ln -s libv4l2.so.0 libv4l2.so sudo ln -s liblcms.so.1 liblcms.so sudo ln -s libcapi20.so.3 libcapi20.so sudo ln -s libcups.so.2 libcups.so sudo ln -s libfontconfig.so.1 libfontconfig.so sudo ln -s libtiff.so.4 libtiff.so sudo ln -s libmpg123.so.0 libmpg123.so sudo ln -s libodbc.so.1 libodbc.so sudo ln -s libopenal.so.1 libopenal.so sudo ln -s libldap-2.4.so.2 libldap.so sudo ln -s libldap_r-2.4.so.2 libldap_r.so sudo ln -s liblber-2.4.so.2 liblber.so sudo ln -s libxml2.so.2 libxml2.so sudo ln -s libxslt.so.1 libxslt.so sudo ln -s libssl.so.0.9.8 libssl.so sudo ln -s libcrypto.so.0.9.8 libcrypto.so sudo ln -s libjpeg.so.8 libjpeg.so sudo ln -s mesa/libGL.so libGL.so cd /usr/lib/i386-linux-gnu/mesa sudo ln -s libGL.so.1 libGL.so cd /lib/i386-linux-gnu sudo ln -s libdbus-1.so.3 libdbus-1.so sudo ln -s libpng12.so.0 libpng.so It is important to note that all the above assumes that you have all the packages you need loaded in ":i386" form. I have not included packages that won't coinstall on amd64 or haven't gotten to work (libhal, libgsm, gstreamer, libgphoto2). If your setup is anything like mine then you'll only need to add a couple more packages: sudo apt-get install libosmesa6:i386 libosmesa-dev libjpeg-turbo8-dev:i386 It's possible that I'm missing a few links, but I've tested the above configuration and it compiles and works for the few things I've opened so far (Firefox, Borderlands, and Diablo III). Erich PS: You may need to work around Bug #30410 (http://bugs.winehq.org/show_bug.cgi?id=30410), without that fix I couldn't play Borderlands. PPS: To get rid of an annoying gnome-keyring message I had to resort to using getlibs (since gnome-keyring is not multi-arch): wget https://launchpad.net/~jcollins/+archive/jaminppa/+build/1482994/+files/getlibs_2.06-0ubuntu1%7Eppa2_all.deb sudo dpkg -i getlibs_2.06-0ubuntu1~ppa2_all.deb getlibs -p gnome-keyring:i386 sudo mkdir /usr/lib/i386-linux-gnu/pkcs11; sudo ln -s /usr/lib32/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so On Wed, Oct 17, 2012 at 2:21 PM, Joey Yandle wrote: >> Is it possible to compile 32bit wine in 64bit ubuntu 12.10? I heard >> there were problems in 12.04 - were they resolved? >> > > I've been happily building 32-bit wine on 64-bit ubuntu 12.04. I just > had to make a debootstrap chroot: > > https://help.ubuntu.com/community/DebootstrapChroot/ > > It only takes a few minutes to setup, given a fast internet connections. > > No idea whether the multiarch conversion has progressed to where this is > no longer necessary. > > Joey > > >
Re: Ubuntu 12.10 - anyone?
On Wed, Oct 17, 2012 at 11:21 PM, Joey Yandle wrote: > I've been happily building 32-bit wine on 64-bit ubuntu 12.04. I just > had to make a debootstrap chroot: > > https://help.ubuntu.com/community/DebootstrapChroot/ > The Wine Wiki page on this has a nice How-to http://wiki.winehq.org/WineOn64bit > It only takes a few minutes to setup, given a fast internet connections. > > No idea whether the multiarch conversion has progressed to where this is > no longer necessary. > Still needed. I just tested it again on 12.10 - many 32bit build dependencies conflict with many 64bit packages (and some of those are dependencies of packages unrelated to Wine...) Thus, building it without a chroot in a "clean" way is not yet possible. Also, building with both sane and tiff support is problematic: libsane-dev wants libtiff5-dev, which conflicts with libtiff4-dev (the one that wine wants) -- Gediminas Jakutis LDK Varčiai www.varciai.lt
re: [PATCH 4/6] [cmd] Add for /f parsingkeyword parsing, add support for skip=
Jason wrote: >>It's clearly time to start splitting WCMD_for into several helper functions. > > I completely agree, and it was definitely on my radar to do... its really > ugly code in there (I take responsibility for a lot of that!) as it has > been a slow incremental increase in what we actually supported... I was > aiming to get a set of working /f tests before I did such a reshuffle as > that is the last of the functionality that for was missing (ie I could > ensure I keep it all working), but will prioritize it if you want it before > that. Seems like it makes sense to add as many tests as possible before refactoring, but if they're messy to submit without also fixing the problems they find, go ahead and keep them local for now... just don't forget to submit them asap. I must say, it's awesome how you're tearing into the cmd problems! - Dan
Re: shell32/tests: Test ShellExecute()'s URL handling.
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 http://testbot.winehq.org/JobDetails.pl?Key=22302 Your paranoid android. === WNT4WSSP6 (32 bit shlexec) === shlexec.c:1800: Test failed: ShellExecute(file="notaproto://foo") succeeded: rc=2 shlexec.c:1803: Test failed: ShellExecute(file="fakeproto://foo/bar") expected SE_ERR_ACCESSDENIED got rc=2 shlexec.c:152: Test failed: ShellExecute(file="shlproto://foo/bar") Got different return value with empty string: 42 2 shlexec.c:152: Test failed: ShellExecute(file="shlproto://foo/bar.lnk") Got different return value with empty string: 42 2 shlexec.c:137: Test failed: ShellExecute(file="file://shlproto://foo/bar") WaitForSingleObject returned 258 shlexec.c:152: Test failed: ShellExecute(file="file://shlproto://foo/bar") Got different return value with empty string: 42 2 shlexec.c:1843: Test failed: ShellExecute(file="file://shlproto://foo/bar") succeeded: rc=42 === W2KPROSP4 (32 bit shlexec) === shlexec.c:1843: Test failed: ShellExecute(file="file://shlproto://foo/bar") succeeded: rc=5 === WVISTAADM (32 bit shlexec) === shlexec.c:1843: Test failed: ShellExecute(file="file://shlproto://foo/bar") succeeded: rc=2 === W2K8SE (32 bit shlexec) === shlexec.c:1843: Test failed: ShellExecute(file="file://shlproto://foo/bar") succeeded: rc=2 === W7PRO (32 bit shlexec) === shlexec.c:1843: Test failed: ShellExecute(file="file://shlproto://foo/bar") succeeded: rc=2 === W7PROX64 (32 bit shlexec) === shlexec.c:1843: Test failed: ShellExecute(file="file://shlproto://foo/bar") succeeded: rc=2 === TEST64_W7SP1 (32 bit shlexec) === shlexec.c:1843: Test failed: ShellExecute(file="file://shlproto://foo/bar") succeeded: rc=2 === W7PROX64 (64 bit shlexec) === shlexec.c:1843: Test failed: ShellExecute(file="file://shlproto://foo/bar") succeeded: rc=2 === TEST64_W7SP1 (64 bit shlexec) === shlexec.c:1843: Test failed: ShellExecute(file="file://shlproto://foo/bar") succeeded: rc=2
Re: Ubuntu 12.10 - anyone?
> Is it possible to compile 32bit wine in 64bit ubuntu 12.10? I heard > there were problems in 12.04 - were they resolved? > I've been happily building 32-bit wine on 64-bit ubuntu 12.04. I just had to make a debootstrap chroot: https://help.ubuntu.com/community/DebootstrapChroot/ It only takes a few minutes to setup, given a fast internet connections. No idea whether the multiarch conversion has progressed to where this is no longer necessary. Joey
Re: [PATCH] winmm: Load winealsa if winepulse is found
Op 17-10-12 20:59, Austin English schreef:
> On Tue, Oct 16, 2012 at 5:10 AM, Maarten Lankhorst
> wrote:
>> From: Maarten Lankhorst
>>
>> Fixes midi on winepulse
>> ---
>> dlls/winmm/lolvldrv.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/dlls/winmm/lolvldrv.c b/dlls/winmm/lolvldrv.c
>> index f387323..3b1be27 100644
>> --- a/dlls/winmm/lolvldrv.c
>> +++ b/dlls/winmm/lolvldrv.c
>> @@ -543,7 +543,10 @@ static void MMDRV_Init(void)
>> drvA = HeapAlloc(GetProcessHeap(), 0, size);
>> WideCharToMultiByte(CP_ACP, 0, pv.u.pwszVal, -1, drvA, size, NULL,
>> NULL);
>>
>> -MMDRV_Install(drvA, drvA, FALSE);
>> +if (!strcasecmp(drvA, "winepulse.drv"))
>> +MMDRV_Install("winealsa.drv", "winealsa.drv", 0);
>> +else
>> +MMDRV_Install(drvA, drvA, FALSE);
>>
>> HeapFree(GetProcessHeap(), 0, drvA);
>> PropVariantClear(&pv);
>> --
>> 1.7.11.3
> Shouldn't this be part of the winepulse patch itself? It will never
> get used in Wine, as is...
Eventually it will, regardless of what driver will be used for it. I intend not
to make that code go unused for too long. See it as a promise.
~Maarten
Re: d3dx9_36 [patch 1/3]: Fix the case out = in for D3DXSHRotateZ
Your patch pass the tests. Good. I think my additionnal tests are enought for now. They prove really well what it happens for this function. I let you send your patch. I will send the tests when your patch is committed. Can you use j++ instead of ++j. Like this, it will be as the other loops for spherical harmonics part. Nozomi. On 17.10.2012 08:35, Nozomi Kodama wrote: > My bad. > > My patch pass the tests but not yours. Can you check these facts? > > Nozomi Oups, I didn't respect the order while setting the output values. Splitting the loop and starting with the smallest index should make the behavior exactly the same as yours (I think). Something like the attached should fix it, please have a look. Though we may use a test for D3DXSHRotateZ(&out[x], y, 1,25f, out)... as of the function gets smaller ... we may generate our expected values by hand. That way we can run all combinations. Not sure if it is worth the effort. Cheers Rico
Re: [PATCH] winmm: Load winealsa if winepulse is found
On Tue, Oct 16, 2012 at 5:10 AM, Maarten Lankhorst
wrote:
> From: Maarten Lankhorst
>
> Fixes midi on winepulse
> ---
> dlls/winmm/lolvldrv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/dlls/winmm/lolvldrv.c b/dlls/winmm/lolvldrv.c
> index f387323..3b1be27 100644
> --- a/dlls/winmm/lolvldrv.c
> +++ b/dlls/winmm/lolvldrv.c
> @@ -543,7 +543,10 @@ static void MMDRV_Init(void)
> drvA = HeapAlloc(GetProcessHeap(), 0, size);
> WideCharToMultiByte(CP_ACP, 0, pv.u.pwszVal, -1, drvA, size, NULL, NULL);
>
> -MMDRV_Install(drvA, drvA, FALSE);
> +if (!strcasecmp(drvA, "winepulse.drv"))
> +MMDRV_Install("winealsa.drv", "winealsa.drv", 0);
> +else
> +MMDRV_Install(drvA, drvA, FALSE);
>
> HeapFree(GetProcessHeap(), 0, drvA);
> PropVariantClear(&pv);
> --
> 1.7.11.3
Shouldn't this be part of the winepulse patch itself? It will never
get used in Wine, as is...
--
-Austin
Ubuntu 12.10 - anyone?
Hello, Is it possible to compile 32bit wine in 64bit ubuntu 12.10? I heard there were problems in 12.04 - were they resolved? Regards, Daniel
RE: msvcp: free facet and _Locimp in Locimp dtor
> You can't add return value to locale__Locimp_dtor since it have to be > compatible with what native returns. I'm not sure how it's supposed to > work, I guess locale__Locimp_dtor should be only called when refcount > already is 0. I'll do some testing tomorrow. How about something like the attached? It moves the call to _Decref up to locale_dtor, so _Locimp_dtor isn't even called if the refcount is non-zero once it does hit zero, it both calls _Locimp_dtor followed by the delete Thanks daniel 0001-msvcp90-move-calling-_Decref-up-to-locale_dtor.patch Description: 0001-msvcp90-move-calling-_Decref-up-to-locale_dtor.patch
Re: msvcp: free facet and _Locimp in Locimp dtor
On 10/17/12 5:04 PM, Daniel Lehman wrote: Memory allocated for locale__Locimp object should be freed in locale class (locale_dtor function). You can't delete it here. Yeah, wasn't entirely sure about the location, but I want to call delete as soon as the refcount is 0 and can only reliably do that there. locale_dtor can't count on refcount when multiple threads are used. should I change locale__Locimp_dtor to return true if locale_dtor should call delete? You can't add return value to locale__Locimp_dtor since it have to be compatible with what native returns. I'm not sure how it's supposed to work, I guess locale__Locimp_dtor should be only called when refcount already is 0. I'll do some testing tomorrow. Cheers, Piotr
Re: (try 3) programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Icns format
On Oct 17, 2012, at 9:50 AM, Aric Stewart wrote: > -if (iconDirEntries[i].wBitCount >= best[slot].maxBits) > +if (((best[slot].maxBits && !scaled) || (!best[slot].maxBits) || > (scaled && best[slot].scaled)) && (iconDirEntries[i].wBitCount >= > best[slot].maxBits || (!scaled && best[slot].scaled))) This could be more clearly written as: if ((!scaled || !best[slot].maxBits || best[slot].scaled) && (iconDirEntries[i].wBitCount >= best[slot].maxBits || (!scaled && best[slot].scaled))) or even: if (scaled && best[slot].maxBits && !best[slot].scaled) continue; /* don't replace unscaled with scaled */ if (iconDirEntries[i].wBitCount >= best[slot].maxBits || (!scaled && best[slot].scaled)) That is, your left side of the outer && has redundancies and all the negatives make it hard to penetrate. -Ken
RE: msvcp: free facet and _Locimp in Locimp dtor
> Memory allocated for locale__Locimp object should be freed in locale > class (locale_dtor function). You can't delete it here. > Yeah, wasn't entirely sure about the location, but I want to call delete as soon as the refcount is 0 and can only reliably do that there. locale_dtor can't count on refcount when multiple threads are used. should I change locale__Locimp_dtor to return true if locale_dtor should call delete? Thanks daniel
Re: [PATCH 4/6] [cmd] Add for /f parsingkeyword parsing, add support for skip=
>It's clearly time to start splitting WCMD_for into several helper functions. I completely agree, and it was definitely on my radar to do... its really ugly code in there (I take responsibility for a lot of that!) as it has been a slow incremental increase in what we actually supported... I was aiming to get a set of working /f tests before I did such a reshuffle as that is the last of the functionality that for was missing (ie I could ensure I keep it all working), but will prioritize it if you want it before that. Jason
Re: (resend) programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Icns format
On 10/17/12 3:11 AM, Per Johansson wrote: > On Wed, Oct 17, 2012 at 6:08 AM, Vincent Povirk wrote: >> I agree that scaling to 32x32 would probably work out better. >> Personally, I probably would've chosen 128x128, since that would >> involve no loss of information or distortion (but maybe we don't like >> the increased file size?). > > It's however much more common that a 32x32 icon is already present. In > fact, checking my own set of wine generated icons, they all already > contain a 32x32 icon. Actually, most contain a 48x48 icon as well. > The issue I am working on resolving here is that many older windows programs only provide a 64x64 icon. With the old code, because there is no 64x64 slot in icns files, these applications where loosing there icons. Ken's suggestion of making sure we do not overwrite a real 48x48 icon is good and I will implement that. -aric
[PATCH] krnl386.exe: Implement INT 33h function 15h
krnl386.exe.diff Description: Binary data
Re: [PATCH 4/6] [cmd] Add for /f parsingkeyword parsing, add support for skip=
Ann and Jason Edmeades writes:
> Parse the options you can provide with for /f to control the
> subsequent parsing, and add support for the simplest (skip).
> @@ -1546,6 +1545,13 @@ void WCMD_for (WCHAR *p, CMD_LIST **cmdList) {
>intitemNum;
>CMD_LIST *thisCmdStart;
>intparameterNo = 0;
> + WCHAR forf_eol=0;
> + intforf_skip=0;
> + WCHAR forf_delims[256];
> + WCHAR forf_tokens[MAXSTRING];
> + BOOL forf_usebackq = FALSE;
> + static const WCHAR forf_defaultdelims[] = {' ', '\t'};
> + static const WCHAR forf_defaulttokens[] = {'1'};
It's clearly time to start splitting WCMD_for into several helper
functions.
--
Alexandre Julliard
julli...@winehq.org
Re: d3dx9_36 [patch 1/3]: Fix the case out = in for D3DXSHRotateZ
On 17.10.2012 08:35, Nozomi Kodama wrote:
My bad.
My patch pass the tests but not yours. Can you check these facts?
Nozomi
Oups, I didn't respect the order while setting the output values.
Splitting the loop and starting with the smallest index should make the
behavior exactly the same as yours (I think). Something like the
attached should fix it, please have a look. Though we may use a test for
D3DXSHRotateZ(&out[x], y, 1,25f, out)... as of the function gets smaller
... we may generate our expected values by hand. That way we can run all
combinations. Not sure if it is worth the effort.
Cheers
Rico
diff --git a/dlls/d3dx9_36/math.c b/dlls/d3dx9_36/math.c
index 220ac31..1190226 100644
--- a/dlls/d3dx9_36/math.c
+++ b/dlls/d3dx9_36/math.c
@@ -3010,68 +3010,44 @@ FLOAT* WINAPI D3DXSHRotate(FLOAT *out, UINT order, CONST D3DXMATRIX *matrix, CON
FLOAT * WINAPI D3DXSHRotateZ(FLOAT *out, UINT order, FLOAT angle, CONST FLOAT *in)
{
-FLOAT c1a, c2a, c3a, c4a, c5a, s1a, s2a, s3a, s4a, s5a;
+UINT i, sum = 0;
+FLOAT c[5], s[5];
TRACE("out %p, order %u, angle %f, in %p\n", out, order, angle, in);
-c1a = cosf(angle);
-s1a = sinf(angle);
+order = min(max(order, D3DXSH_MINORDER), D3DXSH_MAXORDER);
+
out[0] = in[0];
-out[1] = c1a * in[1] + s1a * in[3];
-out[2] = in[2];
-out[3] = c1a * in[3] - s1a * in[1];
-if (order <= D3DXSH_MINORDER)
-return out;
-c2a = cosf(2.0f * angle);
-s2a = sinf(2.0f * angle);
-out[4] = c2a * in[4] + s2a * in[8];
-out[5] = c1a * in[5] + s1a * in[7];
-out[6] = in[6];
-out[7] = c1a * in[7] - s1a * in[5];
-out[8] = c2a * in[8] - s2a * in[4];
-if (order == 3)
-return out;
+for (i = 1; i < order; ++i)
+{
+UINT j;
-c3a = cosf(3.0f * angle);
-s3a = sinf(3.0f * angle);
-out[9] = c3a * in[9] + s3a * in[15];
-out[10] = c2a * in[10] + s2a * in[14];
-out[11] = c1a * in[11] + s1a * in[13];
-out[12] = in[12];
-out[13] = c1a * in[13] - s1a * in[11];
-out[14] = c2a * in[14] - s2a * in[10];
-out[15] = c3a * in[15] - s3a * in[9];
-if (order == 4)
-return out;
+c[i - 1] = cosf(i * angle);
+s[i - 1] = sinf(i * angle);
+sum += i * 2;
-c4a = cosf(4.0f * angle);
-s4a = sinf(4.0f * angle);
-out[16] = c4a * in[16] + s4a * in[24];
-out[17] = c3a * in[17] + s3a * in[23];
-out[18] = c2a * in[18] + s2a * in[22];
-out[19] = c1a * in[19] + s1a * in[21];
-out[20] = in[20];
-out[21] = c1a * in[21] - s1a * in[19];
-out[22] = c2a * in[22] - s2a * in[18];
-out[23] = c3a * in[23] - s3a * in[17];
-out[24] = c4a * in[24] - s4a * in[16];
-if (order == 5)
-return out;
+for (j = i; j > 0; --j)
+{
+if (j != i) out[sum - j] = 0.0f;
+
+out[sum - j] = c[j - 1] * in[sum - j];
+out[sum - j] += s[j - 1] * in[sum + j];
+}
+
+if (in == out)
+out[sum] = 0.0f;
+else
+out[sum] = in[sum];
-c5a = cosf(5.0f * angle);
-s5a = sinf(5.0f * angle);
-out[25] = c5a * in[25] + s5a * in[35];
-out[26] = c4a * in[26] + s4a * in[34];
-out[27] = c3a * in[27] + s3a * in[33];
-out[28] = c2a * in[28] + s2a * in[32];
-out[29] = c1a * in[29] + s1a * in[31];
-out[30] = in[30];
-out[31] = c1a * in[31] - s1a * in[29];
-out[32] = c2a * in[32] - s2a * in[28];
-out[33] = c3a * in[33] - s3a * in[27];
-out[34] = c4a * in[34] - s4a * in[26];
-out[35] = c5a * in[35] - s5a * in[25];
+for (j = 1; j <= i; ++j)
+{
+if (j != i) out[sum + j] = 0.0f;
+
+out[sum + j] = - s[j - 1] * in[sum - j];
+out[sum + j] += c[j - 1] * in[sum + j];
+}
+}
return out;
}
Re: [PATCH 20/25] mciseq: Check stop condition after sleeping. (Try 5)
On Wed, Oct 17, 2012 at 10:36:44AM +0200, joerg-cyril.hoe...@t-systems.com wrote: > Please note that the patch queue failed to detect some superseded patches: > > 90588: I should not have named that 17/25 in the first place. > 90672 + 90674: the original 20-21/25 were never marked superseded by later > patches. > 90841+ 90482: try 3 was superseded by try 4, now superseded by this try 5. I would suggest to resubmit your queue in smaller batches (like eg. 5 pieces per day) and wait for it to get applied. In the current state testbot will not be run on the sequence I think. Ciao, Marcus
Re: testbot/lib: If we cannot open the log file, then log to stderr.
2012/10/16 Francois Gouget > On Mon, 15 Oct 2012, Christian Costa wrote: > [...] > > >> Why not if I can make it run the test after the extraction. > > >> That said why not improving test bot download extra files? Is there a > > >> specific reason for that? > > > I'm not against improving the testbot, it was just a suggestion. > > > > > It's a good one.I will file a bug in bugzilla for the test bot and try > > your suggestion. > > Do you know any simple tool that enables to do that? > > If the sfx approach can be made to work without changes to WineTestBot > then it may be worth documenting somewhere on the Wiki. > > Otherwise I'd rather modify WineestBot to accept .zip files in addition > to .exe ones. This would cause the zip file to be extracted in a > temporary directory, maybe not allowing subdirectories, and the one .exe > file it contains would be run. I think that process would be more > intuitive. > > If we need to allow more than one exe, letting the user specify the > command to run should resolve any ambiguities. > > > That would be perfect!
Re: msvcp: free facet and _Locimp in Locimp dtor
On 10/17/12 02:35, Daniel Lehman wrote: @@ -7241,10 +7241,11 @@ void __thiscall locale__Locimp_dtor(locale__Locimp *this) MSVCP_size_t i; for(i=0; ifacet_cnt; i++) if(this->facetvec[i] && locale_facet__Decref(this->facetvec[i])) -call_locale_facet_vector_dtor(this->facetvec[i], 0); +call_locale_facet_vector_dtor(this->facetvec[i], 1); MSVCRT_operator_delete(this->facetvec); MSVCP_basic_string_char_dtor(&this->name); +MSVCRT_operator_delete(this); } } Memory allocated for locale__Locimp object should be freed in locale class (locale_dtor function). You can't delete it here. Cheers, Piotr
Re: (resend) programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Icns format
On Wed, Oct 17, 2012 at 6:08 AM, Vincent Povirk wrote: > I agree that scaling to 32x32 would probably work out better. > Personally, I probably would've chosen 128x128, since that would > involve no loss of information or distortion (but maybe we don't like > the increased file size?). It's however much more common that a 32x32 icon is already present. In fact, checking my own set of wine generated icons, they all already contain a 32x32 icon. Actually, most contain a 48x48 icon as well. I must admit I'm also no expert at image scaling, but presumably scaling twice is much worse than scaling once, right? In that case I'd say we only want to store a 64 -> 48 scaled icon only if there's no 128, 256 or 512 size icon available, as those would only be scaled once to produce the final image. I'm not so sure it's a good idea to scale upwards, it's better to let the OS scale down an even larger size in that case, if one is available. It's quite uncommon to have larger icons though, at least in my set. > I guess it also depends on what size the OS uses to display the icon. > If it will usually be a particular size, we should probably take that > into account, though I don't know how much we can really do about it. I don't think it's possible to say that it has a usual display size. Default in the Finder seem to be 64x64, but has probably changed over time. Other applications, e.g. launchpad, has larger ones and the dock is dynamic based on the number of items it contains. Regards, -- Per Johansson
Re: [PATCH 3/3] mshtml: Added more ActiveX loading and script binding tests
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 http://testbot.winehq.org/JobDetails.pl?Key=22282 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: testbot/lib: If we cannot open the log file, then log to stderr.
Christian Costa wrote: > >> Indeed that would be great to be able to download some files along with the > >> test. > >> Typically for me avi files and dlls (or .drv) would be great ! :D > > Just do what other tests do: embed all the required data into the test: > > be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. > > That way the tests don't depend on any external files, or abilities in > > the tested environment to download them. > > > It seems a bit complicated for a test I will run only once and not > intended to be part of the test suite. Another approach is how gdi32/tests/font.c embeds wine_test.ttf font file using RCDATA resource. That just adds a simple extraction helper and is pretty trivial and universal for any kind of data file. -- Dmitry.
