Re: [2/4] tools: enable .lnk thumbnailing in Gnome
On Wed, Jul 28, 2010 at 2:54 AM, Scott Ritchie sc...@open-vote.org wrote: On 07/26/2010 03:57 AM, Alexandre Julliard wrote: Damjan Jovanovic damjan@gmail.com writes: diff --git a/tools/Makefile.in b/tools/Makefile.in index a9ec324..a0c9c99 100644 --- a/tools/Makefile.in +++ b/tools/Makefile.in @@ -75,6 +75,8 @@ install install-lib:: wine.inf $(INSTALLDIRS) $(INSTALL_DATA) $(SRCDIR)/l_intl.nls $(DESTDIR)$(datadir)/wine/l_intl.nls $(INSTALL_DATA) $(SRCDIR)/wine.desktop $(DESTDIR)$(datadir)/applications/wine.desktop -$(UPDATE_DESKTOP_DATABASE) + gconftool --set -t string /desktop/gnome/thumbnailers/applicat...@x-ms-shortcut/command wine winemenubuilder -t %i %o || true + gconftool --set -t bool /desktop/gnome/thumbnailers/applicat...@x-ms-shortcut/enable true || true There needs to be a better way of doing this. Probably filing a bug with freedesktop.org is in order. For sure. Thumbnailers are just shell scripts, but there is currently no cross distro way to enable them. My current solution is to just do this at the packaging layer and ignore KDE entirely until someone tells me the equivalent of installing gconf schemas, but this is obviously not good. Thanks, Scott Ritchie freedesktop.org has a spec for a shared thumbnail cache (http://triq.net/~jens/thumbnail-spec/index.html), but no accepted spec for a file browser to request that a file be thumbnailed: there's a draft DBUS thumbnailing spec that's been heavily discussed last year but it still isn't ready or adopted by any/most desktops (http://live.gnome.org/ThumbnailerSpec). I was thinking that what we could do, is when we generate a .lnk file on the desktop, we also write a thumbnail for it to the shared thumbnail cache - that way the desktop environment doesn't need to ask us to generate a thumbnail since it already exists. But then the cache could be cleared out periodically meaning we'd eventually lose the thumbnail. Winemenubuilder could work around this by regenerating all thumbnails that are missing on every startup. But even if this is acceptable solution, it's still hard to implement, because the thumbnail cache spec requires specific thumbnail sizes (128x128 or 256x256) and a special pixel format (256 colour indexed-mode PNG IIRC) which means we'd need to resize and colour convert the icon(s), and it needs special PNG comments on the thumbnails which windowscodecs doesn't support even on Windows AFAIK. So is this idea viable? Thank you Damjan Jovanovic
Re: ddraw: Added a todo_wine test for SetCooperativeLevel
Am 28.07.2010 um 00:39 schrieb Johan Gill: new_ddraw_test.txt The test seems OK to me. Not sure why patchbot is complaining, but it is running in virtual machines, so I guess we can blame its ddraw setup.
Re: [2/4] tools: enable .lnk thumbnailing in Gnome
On 07/28/2010 12:36 AM, Damjan Jovanovic wrote: freedesktop.org has a spec for a shared thumbnail cache (http://triq.net/~jens/thumbnail-spec/index.html), but no accepted spec for a file browser to request that a file be thumbnailed: there's a draft DBUS thumbnailing spec that's been heavily discussed last year but it still isn't ready or adopted by any/most desktops (http://live.gnome.org/ThumbnailerSpec). I was thinking that what we could do, is when we generate a .lnk file on the desktop, we also write a thumbnail for it to the shared thumbnail cache - that way the desktop environment doesn't need to ask us to generate a thumbnail since it already exists. But then the cache could be cleared out periodically meaning we'd eventually lose the thumbnail. Winemenubuilder could work around this by regenerating all thumbnails that are missing on every startup. But even if this is acceptable solution, it's still hard to implement, because the thumbnail cache spec requires specific thumbnail sizes (128x128 or 256x256) and a special pixel format (256 colour indexed-mode PNG IIRC) which means we'd need to resize and colour convert the icon(s), and it needs special PNG comments on the thumbnails which windowscodecs doesn't support even on Windows AFAIK. So is this idea viable? That spec will need to be updated. Gnome recently started supporting thumbnails that are smaller than the overly large 128x128 (actually I think it was 96x96 originally). gnome-exe-thumbnailer now relies on this behavior to render properly, in the past when it was forced to large sizes it looked incredibly ugly. Thanks, Scott Ritchie
Re: [2/2] d3dx9: Implement D3DXAssembleShaderFromFile.
On 27 July 2010 23:32, Matteo Bruni matteo.myst...@gmail.com wrote: +if(parent_data != NULL) +parent_name = *((char **)parent_data - 1); That casts away const. The ID3DXInclude interface itself looks somewhat broken to me, but I don't think you need to modify the parent name here. Please use const char * and const void * or LPCSTR and LPCVOID.
Re: [1/2] d3dx9_36: Handle parent_data parameter of D3DXInclude.Open() function.
On 27 July 2010 23:32, Matteo Bruni matteo.myst...@gmail.com wrote: +if(parent_include == NULL) +ERR(Parent include file missing\n); If that's an internal error, shouldn't the call fail? Similar for the wpp_open_mem() changes.
Re: comctl32/treeview: Fix a crash in TVS_SINGELEXPAND helper (Coverity)
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=3980 Your paranoid android. === WNT4WSSP6 (32 bit treeview) === treeview.c:896: Test failed: got wrong state 60
Re: [PATCH 5/11] quartz: Add MediaSeekingPassThru to video renderer
Maarten Lankhorst m.b.lankho...@gmail.com writes: From 42723d1e254d1fa5b6a64a56d895e05c035780bc Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst m.b.lankho...@gmail.com Date: Sat, 22 May 2010 15:58:15 +0200 Subject: [PATCH 13/32] quartz: Add MediaSeekingPassThru to video renderer It doesn't work here: ../../../tools/runtest -q -P wine -M quartz.dll -T ../../.. -p quartz_test.exe.so filtergraph.c touch filtergraph.ok filtergraph.c:276: Test failed: SetPositions failed: 80040209 filtergraph.c:278: Test failed: SetPositions failed: 80040209 make: *** [filtergraph.ok] Error 2 -- Alexandre Julliard julli...@winehq.org
Re: [3/5] urlmon: Implemented canonicalization for ports in URIs
Thomas Mullaly thomas.mull...@gmail.com writes: --- dlls/urlmon/uri.c | 88 +++- 1 files changed, 86 insertions(+), 2 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so uri.c touch uri.ok uri.c:2788: Test failed: Error: Expected a length of 0 but got -2 on uri_tests[13].str_props[6]. make: *** [uri.ok] Error 1 -- Alexandre Julliard julli...@winehq.org
Re: [2/4] tools: enable .lnk thumbnailing in Gnome
According to MSDN http://msdn.microsoft.com/en-us/library/ee719797%28VS.85%29.aspx#png__image_format, WIC can save indexed color PNG's on Windows. You just need to give it 8-bit indexed image data. Wine's WIC does not support this, but I can work on adding support if there's a real need.
Re: [3/5] urlmon: Implemented canonicalization for ports in URIs
On Wed, Jul 28, 2010 at 8:14 AM, Alexandre Julliard julli...@winehq.orgwrote: Thomas Mullaly thomas.mull...@gmail.com writes: --- dlls/urlmon/uri.c | 88 +++- 1 files changed, 86 insertions(+), 2 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so uri.c touch uri.ok uri.c:2788: Test failed: Error: Expected a length of 0 but got -2 on uri_tests[13].str_props[6]. make: *** [uri.ok] Error 1 Hmm... that's weird. The patch didn't change any of the test cases nor did it even change any of the implementations that it's now failing on. I would like to ask if you could ignore the whole patch set until I figure out what's going on, since the bug might have been introduced earlier in the set. Thanks. -- Thomas Mullaly thomas.mull...@gmail.com
Re: [PATCH] comdlg32/tests: Use GetOpenFileNameA instead of GetOpenFileNameW
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=3990 Your paranoid android. === W7PROX64 (32 bit filedlg) === No test summary line found
Re: [PATCH 1/4] ddraw: Use a less offensive handle table implementation for materials.
Henri Verbeet hverb...@codeweavers.com writes: IDirect3DDeviceImpl_CreateHandle() is particular is just awful. --- dlls/ddraw/ddraw_private.h | 30 - dlls/ddraw/device.c| 63 - dlls/ddraw/direct3d.c | 10 dlls/ddraw/executebuffer.c | 26 -- dlls/ddraw/main.c | 109 dlls/ddraw/material.c | 13 ++--- dlls/ddraw/viewport.c | 34 ++ 7 files changed, 211 insertions(+), 74 deletions(-) Not sure it's really less offensive: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c touch visual.ok visual.c:1770: Tests skipped: device has no P8 texture support, skipping test visual.c:1952: Test failed: IDirect3DMaterial_GetHandle failed: 80070057 visual.c:1989: Test failed: Got color , expected 00ff visual.c:1997: Test failed: Got color , expected 00ff wine: Unhandled page fault on write access to 0x0083 at address 0x686daffd (thread 0024), starting debugger... Unhandled exception: page fault on write access to 0x0083 in 32-bit code (0x686daffd). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:686daffd ESP:0032fa60 EBP:0032fae8 EFLAGS:00010206( R- -- I - -P- ) EAX:0059 EBX:6870b914 ECX:00149058 EDX:001b ESI:04b0 EDI:0097 Stack dump: 0x0032fa60: 6870c5e8 686fbe22 686f95a0 0x0032fa70: 0097 001b 00020808 0x0032fa80: 3f80 00149058 0x0032fa90: 001b 686f954c 6870c70c 686f95a0 0x0032faa0: 686f95d0 6870c5e8 686fbe22 0x0032fab0: 001329e8 Backtrace: =0 0x686daffd IDirect3DDeviceImpl_7_Release+0x25d(iface=0x149058) [/home/julliard/wine/wine/dlls/ddraw/device.c:422] in ddraw (0x0032fb28) 1 0x686cfd60 Thunk_IDirect3DDeviceImpl_1_Release+0x5f(iface=0x149064) [/home/julliard/wine/wine/dlls/ddraw/device.c:474] in ddraw (0x0032fd38) 2 0x686a29fd func_visual+0x155c() [/home/julliard/wine/wine/dlls/ddraw/tests/visual.c:1099] in ddraw_test (0x0032fd88) 3 0x686a2dee run_test+0x15d(name=is not available) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:556] in ddraw_test (0x0032fe48) 4 0x686a2fe7 main+0x156(argc=couldn't compute location, argv=couldn't compute location) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:624] in ddraw_test (0x0032fe90) 5 0x686a3b6c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ddraw_test (0x0032fea8) 6 0x7b85521c call_process_entry+0xb() in kernel32 (0x0032fee8) 7 0x7b85766b start_process+0x5a(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:996] in kernel32 (0x0032fef8) 8 0x7bc72370 call_thread_func+0xb() in ntdll (0x0032ffc8) 9 0x7bc72540 call_thread_entry_point+0x6f(entry=0x7b857610, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2473] in ntdll (0x0032ffe8) 10 0x7bc4d8ca start_process+0x29(kernel_start=0x7b857610) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x) 0x686daffd IDirect3DDeviceImpl_7_Release+0x25d [/home/julliard/wine/wine/dlls/ddraw/device.c:422] in ddraw: movl $0x0,0x68(%edx) 422 m-Handle = 0; -- Alexandre Julliard julli...@winehq.org
Re: [2/4] tools: enable .lnk thumbnailing in Gnome
On 28.07.2010 09:36, Damjan Jovanovic wrote: thumbnails that are missing on every startup. But even if this is acceptable solution, it's still hard to implement, because the thumbnail cache spec requires specific thumbnail sizes (128x128 or 256x256) and a special pixel format (256 colour indexed-mode PNG IIRC) Differing sizes are no problems. Prominent example: if you have picture with an aspect ratio other than 1, the thumbnail won't be square. The file managers usually handle that quite fine ... The spec actually says that thumbnails for small images don't have to be saved; though in practice I'd expect that a 32x32 sized thumbnail shows up as 32x32 (and not scaled up or so). Colors: spec says “it must be a 8bit, non-interlaced PNG image with full alpha transparency”. It's somewhat ambiguous, but indexed colors seem unlikely - 32bit RGBA images (ie 8 bit per channel) is what every thumbnailer practically creates. Link for above info: http://jens.triq.net/thumbnail-spec/creation.html -f.r.
Re: [2/4] tools: enable .lnk thumbnailing in Gnome
On Wed, Jul 28, 2010 at 5:11 PM, Frank Richter frank.rich...@gmail.com wrote: On 28.07.2010 09:36, Damjan Jovanovic wrote: thumbnails that are missing on every startup. But even if this is acceptable solution, it's still hard to implement, because the thumbnail cache spec requires specific thumbnail sizes (128x128 or 256x256) and a special pixel format (256 colour indexed-mode PNG IIRC) Differing sizes are no problems. Prominent example: if you have picture with an aspect ratio other than 1, the thumbnail won't be square. The file managers usually handle that quite fine ... The spec actually says that thumbnails for small images don't have to be saved; though in practice I'd expect that a 32x32 sized thumbnail shows up as 32x32 (and not scaled up or so). Colors: spec says “it must be a 8bit, non-interlaced PNG image with full alpha transparency”. It's somewhat ambiguous, but indexed colors seem unlikely - 32bit RGBA images (ie 8 bit per channel) is what every thumbnailer practically creates. Link for above info: http://jens.triq.net/thumbnail-spec/creation.html -f.r. The PNG thumbnail attributes are the problem then. They require WIC to support metadata writing, which Wine's doesn't atm. Damjan
Re: [PATCH 1/4] ddraw: Use a less offensive handle table implementation for materials.
Oh, I see what happens there. IDirect3DImpl_7_CreateDevice() doesn't zero it's fields during creation. I'll send a patch to have ddraw_handle_table_init() do explicitly itself tomorrow.
Re: shdocvw: Add French translation
On 07/27/2010 10:28 AM, Frédéric Delanoy wrote: We now have an error on the translation site as you've merged 'New' and 'Window'. I know you brought this up on wine-devel but until agreed upon we should stick to the English one IMHO. -- Cheers, Paul.
Re: imm32: Set size of OSVERSIONINFOA before calling GetVersionExA
On Wed, Jul 28, 2010 at 12:46 PM, Matt 'Murph' Finnicum mattf...@gmail.com wrote: This was causing console spam when I played Starcraft 2 (since dwPlatformId was used uninitialized and thus was invalid). Hi Matt, Your patch causes declarations and code in the ImmGetVirtualKey function to be mixed, something that's only permitted in C99. Most likely you'll want to either initialize the size field in the OSVERSIONINFOA struct declaration or move the statement to an appropriate place after the declarations. Andrew
Re: shdocvw: Add French translation
Onsdag 28. juli 2010 18.24.23 skrev Paul Vriens : On 07/27/2010 10:28 AM, Frédéric Delanoy wrote: We now have an error on the translation site as you've merged 'New' and 'Window'. I know you brought this up on wine-devel but until agreed upon we should stick to the English one IMHO. Hello, I forgot to answer that message. I added the New - Window submenu because that is how it is in Microsoft's Internet Explorer 6. It could later include 'E-mail message' and a few other entries. The New submenu was removed in IE7, but I chose to go with IE6 to be consistent with our user interface (and lack of tabs :p ) I could change it if that is desirable, but we should remain consistent across all translations. Regards, Alexander N. Sørnes
wiki slightly broken still?
Creating new wiki pages seems broken today...
Re: wiki slightly broken still?
On Wed, 2010-07-28 at 13:05 -0700, Dan Kegel wrote: Creating new wiki pages seems broken today... Yes, due to all the spam, we've hit the ext3 limit of subdirectories (32k). More here: http://www.rooftopsolutions.nl/blog/135 I'm looking into how we can clean this up. -- Dimi Paun d...@lattica.com Lattica, Inc.
Re: shdocvw: Add French translation
2010/7/28 Paul Vriens paul.vriens.w...@gmail.com: On 07/27/2010 10:28 AM, Frédéric Delanoy wrote: We now have an error on the translation site as you've merged 'New' and 'Window'. I know you brought this up on wine-devel but until agreed upon we should stick to the English one IMHO. -- Cheers, Paul. I resubmitted a fixed version (although functionally similar). Frédéric
Re: shdocvw: Add French translation
2010/7/28 Alexander Nicolaysen Sørnes a...@thehandofagony.com: Onsdag 28. juli 2010 18.24.23 skrev Paul Vriens : On 07/27/2010 10:28 AM, Frédéric Delanoy wrote: We now have an error on the translation site as you've merged 'New' and 'Window'. I know you brought this up on wine-devel but until agreed upon we should stick to the English one IMHO. Hello, I forgot to answer that message. I added the New - Window submenu because that is how it is in Microsoft's Internet Explorer 6. It could later include 'E-mail message' and a few other entries. The New submenu was removed in IE7, but I chose to go with IE6 to be consistent with our user interface (and lack of tabs :p ) I could change it if that is desirable, but we should remain consistent across all translations. OK. I submitted another patch.
Re: wiki slightly broken still?
On 28 July 2010 21:49, Dimi Paun d...@lattica.com wrote: On Wed, 2010-07-28 at 13:05 -0700, Dan Kegel wrote: Creating new wiki pages seems broken today... Yes, due to all the spam, we've hit the ext3 limit of subdirectories (32k). More here: http://www.rooftopsolutions.nl/blog/135 I'm looking into how we can clean this up. Ubuntu hit this one: https://bugs.edge.launchpad.net/ubuntu/+source/moin/+bug/217191 http://moinmo.in/MoinMoinBugs/AllPagesSavedToSingleDirectory The other solution is permanent deletion of the spam pages from the actual file system. I've done such pruning before, and it needs (obviously) to be done with *remarkable* care. It's also very fiddly. I eventually cobbled together scripts to do the deletion for me. (At an old workplace, I don't have them to hand.) The MoinMoin page above lists maintenance scripts that can do it for you. They also suggest moving the wiki directories to a filesystem that can allow stupid amounts of directories, like XFS. (Even ext4 only scales to 64,000 directories.) MoinMoin 2.0 will apparently use a database instead of flat files. ETA: some time or other in the far future. we can't tell exactly when the new storage stuff will be production ready, but I expect end 2008 .. mid 2009. Ahem. Oh, and moinmo.in regards this as not being a bug, but the result of bad file system design. (And not, e.g., a wiki that doesn't scale.) - d.
Re: wiki slightly broken still?
On Wed, Jul 28, 2010 at 1:49 PM, Dimi Paun d...@lattica.com wrote: Yes, due to all the spam, we've hit the ext3 limit of subdirectories (32k). More here: http://www.rooftopsolutions.nl/blog/135 I'm looking into how we can clean this up. Should we also add another hurdle (possibly even manual approval) to make it harder for spammers to get accounts?
Re: wiki slightly broken still?
On Wed, Jul 28, 2010 at 23:35, David Gerard dger...@gmail.com wrote: On 28 July 2010 21:49, Dimi Paun d...@lattica.com wrote: On Wed, 2010-07-28 at 13:05 -0700, Dan Kegel wrote: Creating new wiki pages seems broken today... Yes, due to all the spam, we've hit the ext3 limit of subdirectories (32k). More here: http://www.rooftopsolutions.nl/blog/135 I'm looking into how we can clean this up. Ubuntu hit this one: https://bugs.edge.launchpad.net/ubuntu/+source/moin/+bug/217191 http://moinmo.in/MoinMoinBugs/AllPagesSavedToSingleDirectory The other solution is permanent deletion of the spam pages from the actual file system. I've done such pruning before, and it needs (obviously) to be done with *remarkable* care. It's also very fiddly. I eventually cobbled together scripts to do the deletion for me. (At an old workplace, I don't have them to hand.) The MoinMoin page above lists maintenance scripts that can do it for you. They also suggest moving the wiki directories to a filesystem that can allow stupid amounts of directories, like XFS. (Even ext4 only scales to 64,000 directories.) https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Sub_directory_scalability seems to indicate there is no such limit. Maybe this was the case a couple of years ago. Additionally, migrating from ext3 to ext4 should give the least headaches (maybe a kernel recompile, YMMV) MoinMoin 2.0 will apparently use a database instead of flat files. ETA: some time or other in the far future. we can't tell exactly when the new storage stuff will be production ready, but I expect end 2008 .. mid 2009. Ahem. Oh, and moinmo.in regards this as not being a bug, but the result of bad file system design. (And not, e.g., a wiki that doesn't scale.) - d.
siggraph / opengl BOF tonight
Siggraph happens to be a stone's throw from my house this year, and one of the presenters was my frosh roommate :-), so I'm heading over to the opengl BOF to listen in. ( http://www.khronos.org/news/events/detail/siggraph-la-2010/#topengl_bof ) Email me or google chat me if you want me to try to find out anything...
Re: [6/6] urlmon/tests: Added some more test URIs (resend)
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=4009 Your paranoid android. === WXPPROSP3 (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === WVISTAADM (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === W2K8SE (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2].
Re: [6/6] urlmon/tests: Added some more test URIs (resend)
On Wed, Jul 28, 2010 at 8:09 PM, Marvin test...@testbot.winehq.org wrote: === WXPPROSP3 (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L http://google.com:35; on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === WVISTAADM (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L http://google.com:35; on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === W2K8SE (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L http://google.com:35; on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. There seems to subtle differences between the implementations of CreateUri, since these tests only failed on machines with IE7 installed and passed on the machines with IE8 installed... -- Thomas Mullaly thomas.mull...@gmail.com
Re: siggraph / opengl BOF tonight
On Wed, Jul 28, 2010 at 3:12 PM, Dan Kegel d...@kegel.com wrote: Siggraph happens to be a stone's throw from my house this year, and one of the presenters was my frosh roommate :-), so I'm heading over to the opengl BOF to listen in. ( http://www.khronos.org/news/events/detail/siggraph-la-2010/#topengl_bof ) Roderick was there, and won two prizes in the trivia competition (a graphics card and a copy of an OpenGL debugger from http://www.gremedy.com/ ). Yay Roderick! The BOF was mostly an overview of OpenGL 4.1. - Dan
Re: [PATCH] mmdevapi/tests: Prevent crash when GetMixFormat fails.
On Thu, Jul 29, 2010 at 3:57 AM, Octavian Voicu octavian.vo...@gmail.com wrote: Test results from test.winehq.org show that GetMixFormat consistently fails on some configurations (usually for both capture and render, sometimes only for capture). I also found out why GetMixFormat fails on my system (Kubuntu 10.04). OpenAL returns Pulse Audio as the default device, but pulseaudio daemon is not running (I removed the pulseaudio package from my system). MMDevEnum marks the pulseaudio device as the default one (for both render and capture), but alcOpenDevice / alcCaptureOpenDevice fail so the device is marked with state DEVICE_STATE_NOTPRESENT and openal_setformat is never called (which is the function responsible for writing the DeviceFormat registry key, used by GetMixFormat). A proper fix for the failed GetMixFormat test would be to fall back MMDevice_def_play / MMDevice_def_rec to the 2nd, 3rd, etc device from the default device list, and eventually to the first good device that is found (if all devices from the default device list fail). Is this OK? Octavian
