On Mon Oct 10 12:48:27 CDT 2011, André Hentschel wrote a few things:
Well, in the bug you've mentioned (#5163) there was a link to that file
in mono, but while it seems nice, just looking at mono code makes my
eyes bleed and the perspective of rewriting it in perl would fill me
with terror. There'
Still fails tests here.
Sorry if I wasn't clear before. The wine tests are supposed to pass
after *every* patch in your series. That means you have to
merge patches 2 and 3 together, I think.
On Wed, Oct 12, 2011 at 9:27 PM, wrote:
> This is an experimental automated build and test service.
>
André Hentschel wrote:
> Am 12.10.2011 23:53, schrieb Dan Kegel:
> > When is PATH_MAX not defined?
> >
> > It's part of posix (see
> > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
> > )
> >
> > Are you trying to build on Gnu Hurd?
>
> Yes that's for Hurd. Austin alread
Yeah, I'll recombine them in a bit, but I didn't really remove the test,
per-se, I removed the if/else that performs the test with todo_wine when
the style is PS_USERSTYLE (see the line below, that, of course, is
improperly indented -- why I don't allow single statements in if, else,
while, etc. wi
> OK, I hope [4/3] is acceptable.
It's fine for humans, but for buildbot, you really need to send
the whole patch series again, with the test fixes right in the same
patch as the code that fixes them (so that the wine tree passes
all tests after each patch in the series).
Otherwise your code will
On Wed, Oct 12, 2011 at 19:06, Daniel wrote:
> OK, I hope [4/3] is acceptable. These are the test updates I forgot
> (removes a todo_wine).
Two problems:
A) It needs to be combined with the original patch, so that it passes make test.
B) Why remove the test? Just remove 'todo_wine' itself, since
> Fails the gdi32/pen.ok test here, with error
> pen.c:317: Test succeeded inside todo block: expected 7, got 7
>
> Looks like you need to update a test.
whoops, I forgot about my tests. Will do.
Fails the gdi32/pen.ok test here, with error
pen.c:317: Test succeeded inside todo block: expected 7, got 7
Looks like you need to update a test.
On Wed, Oct 12, 2011 at 4:00 PM, wrote:
> This is an experimental automated build and test service.
> Please feel free to ignore this email while we
Am 12.10.2011 23:53, schrieb Dan Kegel:
> When is PATH_MAX not defined?
>
> It's part of posix (see
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
> )
>
> Are you trying to build on Gnu Hurd?
Yes that's for Hurd. Austin already pointed out dynamic allocation might be a
2011/10/12 Dan Kegel :
> Fails d3d9's visual tests here.
>
> os: Linux 3.0.0-12-generic, Ubuntu 11.10
> gpu: GeForce GT 240/PCI/SSE2 3.3.0 NVIDIA 280.13
>
> On Wed, Oct 12, 2011 at 2:52 PM, wrote:
>> This is an experimental automated build and test service.
>> Please feel free to ignore th
Fails d3d9's visual tests here.
os: Linux 3.0.0-12-generic, Ubuntu 11.10
gpu:GeForce GT 240/PCI/SSE2 3.3.0 NVIDIA 280.13
On Wed, Oct 12, 2011 at 2:52 PM, wrote:
> This is an experimental automated build and test service.
> Please feel free to ignore this email while we work the kinks ou
When is PATH_MAX not defined?
It's part of posix (see
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
)
Are you trying to build on Gnu Hurd?
Apologies I sent this to the wrong list just now.
Ok, Thanks to Dan I have found and corrected the issues that this
created with the tests. I believe all the tests should continue to pass
with this version of the patch.
Has anyone tried it live in any applications?
-aric
---
dlls/user32/
2011/10/12 André Hentschel :
> Might fix the crash in some NT4 systems
> ---
> dlls/shell32/tests/brsfolder.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/shell32/tests/brsfolder.c b/dlls/shell32/tests/brsfolder.c
> index 7b87967..6e5e73b 100644
> --- a/dlls
On Oct 12, 2011, at 1:31 PM, Octavian Voicu wrote:
> On Wed, Oct 12, 2011 at 11:22 PM, Josh Juran wrote:
>> My understanding is that accessing element n or greater in an array[n]
>> is undefined behavior, but declaring a huge array and allocating only
>> part of it is valid.
>
> It's a commonly
On Wed, Oct 12, 2011 at 11:22 PM, Josh Juran wrote:
> My understanding is that accessing element n or greater in an array[n]
> is undefined behavior, but declaring a huge array and allocating only
> part of it is valid.
It's a commonly used pattern in C. You declare a size-one array at the
end of
On Oct 12, 2011, at 10:11 AM, Dmitry Timoshkov wrote:
> Jerome Leclanche wrote:
>
>> It would be nice to fix the "array subscript is above array bounds"
>> warning spam for 1.4.0. They make up 90% of the warnings.
>
> The compiler is misguided, you can safely ignore those warnings.
My understa
On 10/12/2011 02:29 PM, Jerome Leclanche wrote:
> It would be nice to fix the "array subscript is above array bounds"
> warning spam for 1.4.0. They make up 90% of the warnings.
The fix would be to add a configure check for that bogus warning on
access to the array[n]; n > 1
struct _tag {
...
Uwe Bonnes writes:
> @@ -807,8 +808,22 @@ typedef struct async_commio
> static NTSTATUS get_irq_info(int fd, serial_irq_info *irq_info)
> {
> NTSTATUS status = STATUS_NOT_IMPLEMENTED;
> -#ifdef TIOCGICOUNT
> struct serial_icounter_struct einfo;
You can't move this out of the #idef.
On 10/11/2011 09:13 PM, Jeremy White wrote:
I am sad to say that there was a compromise of the WineHQ database system.
"Nothing Is Invulnerable"
So, now or later, your system will be compromised.
The only thing you have to do is to be prepared to face an incident and
of course secure your syste
Jerome Leclanche wrote:
> It would be nice to fix the "array subscript is above array bounds"
> warning spam for 1.4.0. They make up 90% of the warnings.
The compiler is misguided, you can safely ignore those warnings.
--
Dmitry.
On Wed, Oct 12, 2011 at 04:39, Henri Verbeet wrote:
> On 12 October 2011 01:51, Austin English wrote:
>> Current d3d8 does a win_skip(), while d3d9 does a skip(). This unifies
>> the behavior to match the d3d9 behavior.
>>
> I seem to recall this being intentional, so that you get a failure if
>
On Wednesday 12 October 2011 11:35:48 Henri Verbeet wrote:
> On 11 October 2011 22:31, Stefan Dösinger wrote:
> > static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info,
> > enum wined3d_blit_op blit_op,
> >
> > const RECT *src_rect, DWORD src_usage, WINED3DPOOL src_pool
Thank Dan, I had not gotten to a full test run.
I will look into those.
-aric
On 10/11/11 8:01 PM, Dan Kegel wrote:
Hi Aric,
failed again on second run,
http://buildbot.kegel.com:8010/builders/runtests-default/builds/209
Failing tests are
comctl32_test.exe.so listview.c
comctl32_test.exe.so u
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=14844
Your paranoid android
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=14843
Your paranoid android
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.10.2011 um 11:26 schrieb Henri Verbeet:
> On 11 October 2011 22:30, Stefan Dösinger wrote:
>> +if (wined3d_settings.offscreen_rendering_mode == ORM_FBO)
>> +{
>> +if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) ||
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.10.2011 um 11:57 schrieb Henri Verbeet:
> You already have the P8 shader.
My bad. What will actually be added is the NONE conversion with color keying.
But adding a color keying flag is what makes the current approach unsustainable
because it'
On 12 October 2011 11:47, Stefan Dösinger wrote:
> Because when we add more conversions(P8) and settings(color keying) the
> current approach will result ugly unmaintainable if blocks.
>
You already have the P8 shader. In the case of color keying it should
probably at least be in the same series
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.10.2011 um 11:26 schrieb Henri Verbeet:
> Why do you need this?
Because when we add more conversions(P8) and settings(color keying) the current
approach will result ugly unmaintainable if blocks.
-BEGIN PGP SIGNATURE-
Version: GnuPG/M
On 12 October 2011 01:51, Austin English wrote:
> Current d3d8 does a win_skip(), while d3d9 does a skip(). This unifies
> the behavior to match the d3d9 behavior.
>
I seem to recall this being intentional, so that you get a failure if
your setup has e.g. no OpenGL.
On 11 October 2011 22:31, Stefan Dösinger wrote:
> static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info, enum
> wined3d_blit_op blit_op,
> const RECT *src_rect, DWORD src_usage, WINED3DPOOL src_pool, const
> struct wined3d_format *src_format,
> -const RECT *dst_
Why do you need this?
On 11 October 2011 22:30, Stefan Dösinger wrote:
> +if (wined3d_settings.offscreen_rendering_mode == ORM_FBO)
> +{
> +if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) ||
> (dst_usage & WINED3DUSAGE_RENDERTARGET)))
> +return FALSE;
> +}
> +else if (!(d
On 11 October 2011 22:30, Stefan Dösinger wrote:
> +if (wined3d_settings.offscreen_rendering_mode == ORM_FBO)
> +{
> +if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) ||
> (dst_usage & WINED3DUSAGE_RENDERTARGET)))
> +return FALSE;
> +}
> +else if (!(d
35 matches
Mail list logo
