On Tue, Jul 27, 2010 at 12:53 AM, Austin English
wrote:
> Addressing Nikolay and Dmitry's comments.
>
> Passed wtb:
> https://testbot.winehq.org/JobDetails.pl?Key=3947
>
> --
> -Austin
>
>
>
You forgot to attach the patch.
On Tue, Jul 27, 2010 at 12:59 AM, Austin English
wrote:
> --
> -Austin
>
>
>
>
The source file seems to use tabs for indentation, so your patch
should do the same.
On Mon, Jul 26, 2010 at 3:05 PM, Wolfgang Schwotzer
wrote:
> This fixes bug #19397
>
>
>
>
I don't think that's the right place for the fix. You should probably
put it in WS2_sendto. Also could you add some tests to verify that
this is the behavior for all protocols, not just IrDA?
Mike.
On Tue, Jul 27, 2010 at 2:00 AM, Michael Stefaniuc wrote:
> - ok(memcmp(&guid, &IID_Endianess, sizeof(guid)) == 0, "Endianess broken\n");
> + ok(!IsEqualGUID(&guid, &IID_Endianess), "Endianess broken\n");
memcmp returns 0 when there is a match, so you should probably use
IsEqualGUID without the
Dear All:
I have worked hard today with Henri on my D3DXCreateSphere patch and
appreciate all his help (and all of your help and patience with me and
my inability to use email programs and IRC programs ;) ).
I am now moving on to implementing D3DXCreateMeshFVF and ID3DXMesh so
that we can actuall
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=3928
Your paranoid android.
Sorry to do this again, but per:
http://www.winehq.org/pipermail/wine-devel/2010-July/date.html#start
it's been two hours and this has still not made it to the list again.
I am sending attachments as a link, which seems to work:
http://bugs.winehq.org/attachment.cgi?id=29848
I will appreciate al
On Tue, 2010-07-27 at 05:56 +0300, Octavian Voicu wrote:
> On Tue, Jul 27, 2010 at 5:04 AM, Misha Koshelev wrote:
> > Linking same file in test and main dll: I am not aware of a precedent for
> > this but if there is one of course I would be glad to be shown otherwise.
>
> On second thought, not
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=3925
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=3926
Your paranoid android.
On Tue, Jul 27, 2010 at 5:04 AM, Misha Koshelev wrote:
> Linking same file in test and main dll: I am not aware of a precedent for
> this but if there is one of course I would be glad to be shown otherwise.
On second thought, not sure if it is worth it anyway, there is
probably not that much to s
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=3924
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=3921
Your paranoid android.
Ok I am very very sorry email is clearly not my forte.
Linking same file in test and main dll: I am not aware of a precedent for
this but if there is one of course I would be glad to be shown otherwise.
Second comment: please pardon if I am misunderstanding but how is what you
suggest not simply
Sorry mobile gmail for android does not allow bottom post. Maybe someone can
suggest better way to reply.
Code sharing between tests and dll: I honestly dont know of a good way but I
would be very surprised if something like linking the same fil
On Jul 26, 2010 8:40 PM, "Octavian Voicu" wrote:
On Tue, Jul 27, 2010 at 4:15 AM, Misha Koshelev wrote:
> Why do you ask?
>
> Are you aware of a good way to share code between tests and the actual
> function?
That's why I was asking, as I suppose you can't use functions from the
test in the implementation, nor have internal functions used in t
> On Tue, Jul 27, 2010 at 1:30 AM, Misha Koshelev wrote:
> > I have spent quite a bit of time with Henri on IRC re this patch (thank you
> > so much) and it now has his blessing.
> >
> > Hopefully everyone else's as well :)
>
> Looks nice, but I have a question.
>
> When you're going to actuall
On Tue, Jul 27, 2010 at 1:30 AM, Misha Koshelev wrote:
> I have spent quite a bit of time with Henri on IRC re this patch (thank you
> so much) and it now has his blessing.
>
> Hopefully everyone else's as well :)
Looks nice, but I have a question.
When you're going to actually implement D3DXCr
2010/7/26 Rico Schüller :
> +/* 32 (DXBC header) + 2 * (1 * 4 (chunk index) + 2 * 4 (chunk header)) +
> data_size (chunk data) */
I'm probably missing something here, but:
- I think that should be "2 * 4 (chunk index) + 2 * 4 (chunk header)" -> 48?
- Aligning chunks on 16 byte / 128 bits
2010/7/26 Rico Schüller :
> +static HRESULT shader_singnature_handler(const char *data, DWORD data_size,
> DWORD tag, void *ctx)
That's not how you write "signature".
> +IUnknown_Release((IUnknown *)object);
Is that cast needed?
2010/7/26 Rico Schüller :
> +IUnknown_Release((IUnknown *)object);
Since you'll probably resend this anyway based on Matteo's comment, I
think just HeapFree() should do just as well. Also, I don't have a
recent enough DX SDK to check at the moment, but if d3dcommon.h is
generated by IDL, it
On 26 July 2010 21:21, Matteo Bruni wrote:
> // ID3D10Blob has been made version-neutral and moved to d3dcommon.h.
>
Actually, since this comes up now, perhaps this is a good time to
think about implementing d3dcompiler and d3dx10? I think we'll have to
anyway at some point, and perhaps it's bette
On Mon, Jul 26, 2010 at 3:26 PM, James Mckenzie
wrote:
>
> Just a question, I don't see 1/6 in this sequence. Was it submitted
> earlier?
>
> I sent it, but somehow it must have gotten lost along its digital path. It
shows up in my gmail sent mail folder.
Dylan:
Just a question, I don't see 1/6 in this sequence. Was it submitted earlier?
James
-Original Message-
>From: Dylan Smith
>Sent: Jul 26, 2010 5:26 AM
>To: wine-patches
>Subject: [2/6] richedit: EN_UPDATE notification is sent on WM_PAINT.
>
Hello Rico,
from d3d10misc.h of latest DirectX SDK:
// ID3D10Blob has been made version-neutral and moved to d3dcommon.h.
d3dcommon.h seems to be an idl-generated header. From what I can see
up to now, only your first patch is "wrong", the rest just needs to be
fixed to include d3dcommon.h where
On Mon, Jul 26, 2010 at 12:38 PM, Travis Athougies wrote:
> Resending patch with proper line wrapping
You forgot the patch :-).
--
-Austin
On Mon, Jul 26, 2010 at 2:13 PM, Uwe Bonnes
wrote:
> +#else
> +const SSL_METHOD *method;
Also, you accidentally removed the "static" keyword instead of
removing the "const" keyword for the #else branch (in both files).
Octavian
On Mon, Jul 26, 2010 at 2:13 PM, Uwe Bonnes
wrote:
> -static SSL_METHOD *meth;
> +#if defined(OPENSSL_VERSION_NUMBER) && (OPENSSL_VERSION_NUMBER> 0x100)
> +static const SSL_METHOD *meth;
> +#else
> +const SSL_METHOD *method;
There's a typo here, last line should declare meth not method.
Octa
On 26 July 2010 17:08, Michael Stefaniuc wrote:
> Works for me with the gcc 4.4.4 on F13 but it breaks with the old 3.1.1
> gcc used by the old Smatch.
>
Well, it works with 4.4.3 on Gentoo for me as well... :-) just saying
that you don't necessarily have to try very hard to break it.
Henri Verbeet wrote:
> On 26 July 2010 10:00, Alexandre Julliard wrote:
>> Octavian Voicu writes:
>>
>>> On Sun, Jul 25, 2010 at 11:36 PM, Mikko Rasa wrote:
-static const DWORD user_flags = clip_flags | DCX_NORESETATTRS; /*
flags that can be set by user */
+static const D
Piotr Caban writes:
> try3: Don't skip all tests on 64bit
You should be able to run all tests on 64-bit, which would also have the
advantage of making sure the function prototypes are correct (since the
call macros on i386 prevent checking).
--
Alexandre Julliard
julli...@winehq.org
On 26 July 2010 15:58, Uwe Bonnes
wrote:
> Wrapper DLLs, where possible, are much more favorable. They don't require
> server calls for each function call.
I'd imagine proper USB support wouldn't either. That said, I don't
know for sure if that's the real reason either, it could also be a
specific
Hi Alexander,
On 7/26/10 11:36 AM, Alexander Nicolaysen Sørnes wrote:
In preparation for adding a status bar to Wine's IE
-static const WCHAR wszDone[] = {'D','o','n','e',0};
+static WCHAR wszDone[40] = { 0 };
+
+if(!wszDone[0])
+LoadStringW
> "Henri" == Henri Verbeet writes:
Henri> On 26 July 2010 13:28, Uwe Bonnes
Henri> wrote:
>> there are several hardware related libraries, like libusb and
>> libftd2xx which exist on Windows and at least linux. I tried already
>> to add libftd2xx, but with silent reject.
On 26 July 2010 13:28, Uwe Bonnes
wrote:
> there are several hardware related libraries, like libusb and libftd2xx
> which exist on Windows and at least linux. I tried already to add libftd2xx,
> but with silent reject.
>
> What is the preferred way to handle it? I feel including in wine is
> favo
On 26 July 2010 10:00, Alexandre Julliard wrote:
> Octavian Voicu writes:
>
>> On Sun, Jul 25, 2010 at 11:36 PM, Mikko Rasa wrote:
>>> - static const DWORD user_flags = clip_flags | DCX_NORESETATTRS; /*
>>> flags that can be set by user */
>>> + static const DWORD user_flags = DCX_PARENTC
On 26 July 2010 01:20, Misha Koshelev wrote:
> I kept some macros in, although I know you guys don't like that too much.
>
> Like sphere_vertex. I think it makes the code clearer.
compare_vertex and compare_face are probably ok, but there's no reason
sphere_vertex can't be an inline function. Note
2010/7/25 :
> +if(pDestRect->left > pDestRect->right || pDestRect->top >
> pDestRect->bottom) return D3DERR_INVALIDCALL;
> +if(pDestRect->left > surfdesc.Width || pDestRect->right >
> surfdesc.Width) return D3DERR_INVALIDCALL;
If left <= right <= Width, left can never be > Width
On 25 July 2010 19:15, wrote:
> +typedef struct
> {
> +CONST PixelFormatDesc *srcformat;
> +CONST PixelFormatDesc *destformat;
> DWORD srcshift[4], destshift[4];
> DWORD srcmask[4], destmask[4];
> BOOL process_channel[4];
> -DWORD channels[4];
> -DWORD channelmask
On 24 July 2010 17:33, Misha Koshelev wrote:
> Thus, I thought I'd pose the question - as to d3dx9, is our goal:
> a) speed
> b) code "prettiness"
> c) something else?
>
> I am tempted to think it is (a), but wanted to double check.
>
In the general case, maintainability. That includes things like
Hello,
there are several hardware related libraries, like libusb and libftd2xx
which exist on Windows and at least linux. I tried already to add libftd2xx,
but with silent reject.
What is the preferred way to handle it? I feel including in wine is
favorable, as this gives a good user impression,
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=3902
Your paranoid android.
Damjan Jovanovic 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)/
David Hedberg writes:
> ---
> dlls/shell32/Makefile.in |1 +
> dlls/shell32/shell32.spec |1 +
> dlls/shell32/shellitemarray.c | 270
>
> dlls/shell32/tests/shlfolder.c | 132 +++
> include/shobjidl.idl |
Piotr Caban writes:
> @@ -22,6 +22,13 @@
> #include
> #include "wine/test.h"
>
> +#ifndef __i386__
> +/* Skip these tests for non x86 platforms */
> +START_TEST(misc)
> +{
> +}
> +#else
There's no reason not to run the tests on 64-bit, as long as the
functions exist there, they should be te
Octavian Voicu writes:
> On Sun, Jul 25, 2010 at 11:36 PM, Mikko Rasa wrote:
>> - static const DWORD user_flags = clip_flags | DCX_NORESETATTRS; /* flags
>> that can be set by user */
>> + static const DWORD user_flags = DCX_PARENTCLIP | DCX_CLIPSIBLINGS |
>> DCX_CLIPCHILDREN | DCX_WINDO
46 matches
Mail list logo
