Re: gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text. Take 2.
This looks correct to me. Lack of shared logic and GenericTypographic still makes me sad, but not too sad because the added logic is simple.
Re: About WineHQ Wiki
28.08.2012 19:50, Kyle Auble пишет > If you're mainly noticing problems with the wiki, that may also be > that we're using an outdated version of moinmoin. Cheer Xiao was saying > that Moinmoin 2.0 will allow Mediawiki syntax so I'd recommend > upgrading Moinmoin, then converting the pages to Mediawiki syntax. Well, let`s try. However, I believe all the content on WineHQ & the wiki are under the LGPL so if you really wanted to, I'd think you could try testing a mirror of the site as a proof of concept, running Cherokee on your own computer. Well, that`t a good idea to run Wikimedia version at my computer. In addition, I will be able make all configuration properly. I will write there, when I buy a static address at my provider and get a domain name, OK? Rather than switching out the http server, I think there is some interest in moving WineHQ over to a web-framework/CMS. Thank you!I got an idea to create CMS-based WineHQ site mirror on my computer too. --- Oleg
Re: Wine bot results
* On Tue, 28 Aug 2012, Saulius Krasuckas wrote: > * On Tue, 28 Aug 2012, Alistair Leslie-Hughes wrote: > > > > > Target: i686-w64-mingw32 > ... > > Target: i586-mingw32msvc > > There was the same topic brought up two years ago: > http://www.winehq.org/pipermail/wine-devel/2010-September/086643.html > > IIRC, MSVC and i586-mingw32msvc compilers initialize every declared > variable while *-mingw32* one does not. I mean *-mingw32-gcc (the one not using MSVCRT.DLL) with the latter;) S.
Re: Wine bot results
* On Tue, 28 Aug 2012, Alistair Leslie-Hughes wrote: > > > Target: i686-w64-mingw32 ... > Target: i586-mingw32msvc There was the same topic brought up two years ago: http://www.winehq.org/pipermail/wine-devel/2010-September/086643.html IIRC, MSVC and i586-mingw32msvc compilers initialize every declared variable while *-mingw32* one does not. S.
Re: About WineHQ Wiki
Tues, Aug 28, 2012 4:47 AM, Oleg Yarigin wrote: > Now I wait an answer from Dimi Paun. > > > Well, in addition, how do you think, is any necessarity there to move > wine site and wiki from Apache to Cherokee? While I think it's good to keep alternatives in mind as new technology comes out, I wouldn't want to switch the actual http server out until it starts having noticeable problems, or in the distant future once higher priorities have been taken care of. For me, WineHQ itself seems to be really fast, and as we were discussing earlier in the thread, the wiki is hosted at Lattica, which may not have the same hardware resources or bandwidth of WineHQ. If you're mainly noticing problems with the wiki, that may also be that we're using an outdated version of moinmoin. Cheer Xiao was saying that Moinmoin 2.0 will allow Mediawiki syntax so I'd recommend upgrading Moinmoin, then converting the pages to Mediawiki syntax. I've never run a real Apache server myself (just played with it on my computer), but while it can be a pain to set up, it is battle-tested. Since the site admins would have to do all the dirty work, I feel like this should be their call in the end. However, I believe all the content on WineHQ & the wiki are under the LGPL so if you really wanted to, I'd think you could try testing a mirror of the site as a proof of concept, running Cherokee on your own computer. If you can show the advantages outweigh the trouble of switching over, the site admins would probably be more willing to consider it. Rather than switching out the http server, I think there is some interest in moving WineHQ over to a web-framework/CMS. I wanted to handle the wiki first, but afterwards if there's still demand for it, I'd like to try helping make the jump to a CMS. -Kyle
Re: Wine bot results
On 08/28/12 12:04, Alistair Leslie-Hughes wrote: > Hi, > > I have a patch that when run on on the testbot, it fails on all but > two machines. > However when I build the exe myself and run it, it pass on all but two > machines. > > http://testbot.winehq.org/JobDetails.pl?Key=21257 > http://testbot.winehq.org/JobDetails.pl?Key=21256 > > Ubuntu 12.04. > > Any Ideas on the different results? + VariantClear(&d); + V_VT(&v) = VT_BSTR; + V_BSTR(&v) = SysAllocStringLen(NULL, 0); This VariantClear call attempts to free uninitialized VARIANT instance. You probably meant VariantInit(). Jacek
Re: About WineHQ Wiki
On 08/28/2012 04:47 AM, Oleg Yarigin wrote: Well, in addition, how do you think, is any necessarity there to move wine site and wiki from Apache to Cherokee? Not going to happen anytime in the near future. I won't say never however. -N
Re: [PATCH 1/5] d3dx9: Add some traces to D3DXLoadSurfaceFromMemory().
2012/8/28 Rico Schüller :
> +FIXME("Format conversation missing %#x -> %#x\n", src_format,
> surfdesc.Format);
I don't think that's really what we want it to say.
Re: shell32: Make ShellExecute use native file association databases as fallback path (resend)
Erik van Pienbroek writes:
> +#if defined(HAVE_FORK) && defined(HAVE_WAITPID)
> +static UINT_PTR SHELL_try_native_execute ( const char *openCmd, const char
> *unixName )
> +{
> +UINT_PTR retval = SE_ERR_NOASSOC;
> +pid_t cpid;
> +struct stat st;
> +
> +if (stat(openCmd, &st) == -1)
> +{
> +TRACE("stat() %s failed: %s\n", openCmd, strerror(errno));
> +return retval;
> +}
> +
> +cpid = fork();
> +if (!cpid)
> +{
> +/* Prevent the situation where the native file association database
> + * tries to run wine to execute a program and we trigger this
> fallback
> + * path again and end up in a recursive loop */
> +if (getenv("WINE_INSIDE_SHELLEXECUTE"))
> +{
> +TRACE("recursive loop detected, not continuing with ShellExecute
> call\n");
> +exit(EXIT_SUCCESS);
> +}
> +setenv("WINE_INSIDE_SHELLEXECUTE", "1", 0);
> +
> +TRACE("running %s %s\n", openCmd, unixName);
> +execlp(openCmd, openCmd, unixName, (char*) NULL);
> +/* execlp replaces the current process image with a new process
> image,
> + * so no code below here should get executed by the forked child */
> +} else {
> +int status;
> +waitpid(cpid, &status, 0);
> +TRACE("status %x\n", status);
> +if(!WEXITSTATUS(status))
> +retval = 33;
> +}
> +
> +return retval;
> +}
You want spawnvp(), but that sort of thing should probably go in
winebrowser or something like that, and be configurable.
--
Alexandre Julliard
julli...@winehq.org
Re: kernel32: Try to get the drive type from the mountmgr first [resend]
Alexandre Goujon writes: > Should fix bug #17037 > Now that my patch disappeared from source.winehq.org/patches, I'm resending > it. > Before commenting, please read the e-mail I sent in July > (winehq.org/pipermail/wine-devel/2012-July/096587.html) The goal here is to avoid a mountmgr round-trip for the common case, calling mountmgr first defeats this. -- Alexandre Julliard julli...@winehq.org
Re: d3dx9: ID3DXConstantTable
On 28.08.2012 10:50, Henri Verbeet wrote: On 28 August 2012 09:12, Rico Schüller wrote: 3. The wine_todo should be fixed in the test. Is there a way to disable them to show up, when running e.g. "wine d3dx9_36_test.exe.so shader"? It's a bit annoying when you search for your own failing tests. Well I could comment out the tests, but that's also not a very fine solution. You can set WINETEST_PLATFORM=wine, but the easiest is probably to just do "make shader.ok" instead of trying to run the test manually. Thanks, that's exactly what I need. Cheers Rico
Re: Wine bot results
Hi Qian, $ i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.6.1/lto-wrapper Target: i686-w64-mingw32 Configured with: ../../src/configure --build=i686-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --disable-shared --disable-multilib --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran --enable-lto --with-plugin-ld --enable-fully-dynamic-string --target=i686-w64-mingw32 --with-gxx-include-dir=/usr/include/c++/4.6 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld Thread model: win32 gcc version 4.6.1 (GCC) $ i586-mingw32msvc-gcc -v Using built-in specs. Target: i586-mingw32msvc Configured with: /build/buildd/mingw32-4.2.1.dfsg/build_dir/src/gcc-4.2.1-2-dfsg/configure -v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++ --enable-threads --enable-sjlj-exceptions --disable-multilib --enable-version-specific-runtime-libs Thread model: win32 gcc version 4.2.1-sjlj (mingw32-2) Here is what install on my system, Ill try to update it to a later version. Best Regards Alistair Leslie-Hughes
Re: [PATCH 6/6] Always define WIDL_C_INLINE_WRAPPERS
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=21287 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [PATCH 6/6] Always define WIDL_C_INLINE_WRAPPERS
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=21286 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [PATCH 6/6] Always define WIDL_C_INLINE_WRAPPERS
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=21285 Your paranoid android. === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: Wine bot results
Hello Alistair, On Tue, Aug 28, 2012 at 6:04 PM, Alistair Leslie-Hughes wrote: > http://testbot.winehq.org/JobDetails.pl?Key=21257 > http://testbot.winehq.org/JobDetails.pl?Key=21256 I downloaded your patch from http://testbot.winehq.org/GetFile.pl?JobKey=21257&StepKey=1 , compiled with i686-w64-mingw32-gcc on Ubuntu 10.10, then resubmit it to wine testbot, my result is the same as the one built by testbot: https://testbot.winehq.org/JobDetails.pl?Key=21288 Maybe it is interesting to know what compiler you use and which one is used by testbot. Though we should make sure we are always test on the same patch first =) $ i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.6.1/lto-wrapper Target: i686-w64-mingw32 Configured with: ../../src/configure --build=i686-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --disable-shared --disable-multilib --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran --enable-lto --with-plugin-ld --enable-fully-dynamic-string --target=i686-w64-mingw32 --with-gxx-include-dir=/usr/include/c++/4.6 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld Thread model: win32 gcc version 4.6.1 (GCC) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Wine bot results
Alistair Leslie-Hughes wrote: > I have a patch that when run on on the testbot, it fails on all but two > machines. > However when I build the exe myself and run it, it pass on all but two > machines. > > http://testbot.winehq.org/JobDetails.pl?Key=21257 > http://testbot.winehq.org/JobDetails.pl?Key=21256 > > Ubuntu 12.04. > > Any Ideas on the different results? This probably means that behaviour is undefined and depends on memory contents. -- Dmitry.
Wine bot results
Hi, I have a patch that when run on on the testbot, it fails on all but two machines. However when I build the exe myself and run it, it pass on all but two machines. http://testbot.winehq.org/JobDetails.pl?Key=21257 http://testbot.winehq.org/JobDetails.pl?Key=21256 Ubuntu 12.04. Any Ideas on the different results? Best Regards Alistair Leslie-Hughes
Re: About WineHQ Wiki
Finally I got an answer from Jeremy White, wine site admin: Hi Oleg, On 08/26/2012 08:21 AM, Oleg Yarigin wrote: Good time of a day, Jeremy. I write to you as to a WEB-administrator of WineHQ server about some ideas of site functionality improvement: 1. How is about moving WineHQ Wiki onto Wikimedia engine and break it into multiple language trurd-level domains (like interwiki in Wikipedia)? I am ready to move the Wiki`s material from old one (wiki.winehq.org) to new one. A discussion of this idea is in August wine-devel pipemail, "About WineHQ Wiki" thread. I'm afraid that this is something best discussed on the wine-devel list. And the person you really need to persuade is Dimi Paun - he runs the Wiki. 2. How is about moving a whole site from Apache web server to Cherokee web server? I heared, it is much faster. Are we having a problem with Apache being too slow? I think you'll find us very reluctant to make change for no driving reason. Again, if you are finding a problem with the current web site, please share that on the wine-devel mailing list. Cheers, Jeremy Now I wait an answer from Dimi Paun. Well, in addition, how do you think, is any necessarity there to move wine site and wiki from Apache to Cherokee? --- Oleg
Re: gdiplus: When copying an image do not round pixel positions up.
Vincent Povirk wrote: > >> I just did, and the behavior, though it looks wrong, is the same > >> between builtin and native - the image is shifted by 1/2 pixel so that > >> it's cut off at the upper-left and we have extra transparent space at > >> the lower-right. > > > > With native gdiplus scenario described earlier works just fine for me, > > while with built-in there are black borders on bottom/right. > > You should be getting transparent borders on the bottom/right. > > This probably means you're using a surface that's not capable of alpha > blending, and in that situation gdi_alpha_blend currently draws fully > transparent pixels as black when it shouldn't. I'm pretty sure I > mentioned that as a problem earlier, around the time you introduced > gdi_alpha_blend. The problem is not related to a device not supporting alpha blending, I even replaced a TRACE there by ERR just in case, but it never triggers. > If you compare the size of the image drawn between native/builtin (not > counting the border, which native draws as transparent, as does > builtin under normal circumstances), I think you'll find that it > currently matches and your patch changes it. If you didn't notice, > you're probably not enlarging the image enough. I don't see a difference in the image size regardless how much I enlarge the image. > Since GdipDrawImage doesn't accept a source rectangle, and those extra > pixels are supposed to be transparent, you could probably have > GdipDrawImage subtract 0.5 from your image width and height. That > should solve your problem in this limited case without fixing > gdi_alpha_blend or introducing a bug. Subtracting 0.5 from width and height hides the problem, but that's just a compensation to rounding up that my patch is removing. -- Dmitry.
Re: d3dx9: ID3DXConstantTable
On 28 August 2012 09:12, Rico Schüller wrote: > 3. The wine_todo should be fixed in the test. Is there a way to disable them > to show up, when running e.g. "wine d3dx9_36_test.exe.so shader"? It's a bit > annoying when you search for your own failing tests. Well I could comment > out the tests, but that's also not a very fine solution. > You can set WINETEST_PLATFORM=wine, but the easiest is probably to just do "make shader.ok" instead of trying to run the test manually.
Re: xmllite: Store DTD processing mode in reader
Dan Kegel writes:
> Alexandre Julliard wrote:
>> Explicit ok() calls are better than hiding them inside a macro.
>
> Uh-oh. Want me to get rid of this macro
>
> +#define CHECK_RET_ERRNO(ret, ex) \
> +do { \
> +ok(ret == ex, "ret is %d, expected %d\n", ret, ex); \
> +ok(errno == ex, "errno is %d, expected %d\n", errno, ex); \
> +} while (0)
>
> in http://source.winehq.org/patches/data/89349 ?
Obviously, yes.
--
Alexandre Julliard
julli...@winehq.org
Re: d3dx9: ID3DXConstantTable
On 23.08.2012 22:58, Rico Schüller wrote: On 23.08.2012 15:43, Józef Kucia wrote: I would prefer you to clean it up submit it. I hope it gets committed this time. Ok, I'll try to clean them and send them. I will do it the safe way and compare each handle with all handles we have. If it is slow, we could easily move by using the highest bit for comparison against the D3DXHANDLE. We just have to take care that an easy switch is possible. Thanks for the input. Rico Patches are in git now. The normal way should work fine. The following things should be considered (but I have no patches for these): 1. The cross calling (table1, variable_from_table2). 2. We may avoid the desc copy, because the variables may be set often and so the copy time will make some speed difference in set_*_array and GetSamplerIndex. Example for GetSamplerIndex: res = ID3DXConstantTable_GetConstantDesc(iface,constant,&desc,&count); if (FAILED(res)) return (UINT)-1; if (desc.RegisterSet != D3DXRS_SAMPLER) to something like: struct ctab_constant *c = get_valid_constant(This, constant); if (c->desc.RegisterSet != D3DXRS_SAMPLER) 3. The wine_todo should be fixed in the test. Is there a way to disable them to show up, when running e.g. "wine d3dx9_36_test.exe.so shader"? It's a bit annoying when you search for your own failing tests. Well I could comment out the tests, but that's also not a very fine solution. Cheers Rico
