Hello
What is the problem with patch
http://source.winehq.org/patches/data/97500
M_PI is never used in D3DX.
Nozomi
What is the problem with patch: http://source.winehq.org/patches/data/97500
M_PI is never used in D3DX (moreover it is deprecated in C99)
Nozomi
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=26523
Your paranoid android
On Tue, Jul 30, 2013 at 5:13 PM, Bruno Jesus <00cp...@gmail.com> wrote:
>
>
You forgot the patch.
--
-Austin
Please ignore this patch, I understand that as is it will not be commited.
On Tue, Jul 30, 2013 at 3:30 AM, Bruno Jesus <00cp...@gmail.com> wrote:
> Erich Hoover contacted me about a patch he sent months ago related to
> GetVolumePathNameA. He developed a better test infrastructure using a
> for l
2013/7/30 Rico Schüller :
> Hi Matteo,
>
> please see the attached patch.
>
>
> On 25.07.2013 16:13, Matteo Bruni wrote:
>>
>> 2013/7/24 Rico Schüller :
>>>
>>> ---
>>> dlls/d3dx9_36/tests/shader.c | 308
>>> +++
>>> 1 file changed, 308 insertions(+)
>>>
>
Hi Matteo,
please see the attached patch.
On 25.07.2013 16:13, Matteo Bruni wrote:
2013/7/24 Rico Schüller :
---
dlls/d3dx9_36/tests/shader.c | 308
+++
1 file changed, 308 insertions(+)
This is okay, but as a followup can you add some tests with m
I think I've seen patches stay in the "New" state in the following cases:
* He's convinced you do not have the ability to write a patch he
would accept. (There's a common pattern where people will take
feedback and attempt to revise their patch to account for it, but not
really understand the feed
Hello Nikolay,
On Wed, Jul 10, 2013 at 1:06 AM, Nikolay Sivov wrote:
> This could be some a different bug, and putting exception handler around it
> is not necessary a right solution.
Good catch, I think you are right.
I found ImmLockIMC()/ImmUnLockIMC()/etc are called even after
ImmDestroyCont
Forgot to say, as described in the last post, this patch doesn't kill
the culprit, please reject the patch, thanks.
Hi, I'm looking for help to test WSAEnumProtocols, I need to collect
more information about the values returned from different versions of
windows, especially 7 and 8.
If you can help please download the file below, unzip, run the .bat
and send me back the result.txt file (sources included).
http:
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> You shouldn't check the version, but the actual problem (i.e. the size
>> of the offending type). Also please avoid unnecessary changes.
>
> The offending type is toff_t, it's size is either 32 or 64-bit depending
> on whether it's libtif
Alexandre Julliard wrote:
> You shouldn't check the version, but the actual problem (i.e. the size
> of the offending type). Also please avoid unnecessary changes.
The offending type is toff_t, it's size is either 32 or 64-bit depending
on whether it's libtiff 3.0 or 4.0, or whether it's broken
There's also "Pending".
On 30/07/13 04:16, Hugh McMaster wrote:
Hi everyone,
Wine patches currently have a status described in
http://source.winehq.org/patches, yet for patches with the status of 'New', the
status becomes confusing.
The legend describes 'New' status as "Patch not even looked
Hi Nikolay,
On 07/30/13 12:42, Nikolay Sivov wrote:
> +dst = &This->attr[index];
> +src = &This->attr[index+1];
> +
> +memmove(dst, src, This->length-index-1);
*sizeof(*dst)
Cheers,
Jacek
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> >> TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined
>> >> to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43.
>> >>
>> >> Unfortunately TIFFLIB_VERSION define reflects the date, not the real
>> >> version. So for i
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=26481
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=26482
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=26480
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=26479
Your paranoid android
Alexandre Julliard wrote:
> >> TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined
> >> to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43.
> >>
> >> Unfortunately TIFFLIB_VERSION define reflects the date, not the real
> >> version. So for instance libtiff 3.9.7 has it define
On 07/29/13 17:55, Caibin Chen wrote:
>> +struct tagReTxtDoc {
>> + IUnknown *outerObj;
>> + ME_TextEditor *editor;
>> + ITextDocument iTextDocumentIface;
>> +};
>>
>> Do you really need a separated structure for that? Wouldn't adding
>> ITextDocument implementation to ITextServicesImpl be enou
Dmitry Timoshkov writes:
>> TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined
>> to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43.
>>
>> Unfortunately TIFFLIB_VERSION define reflects the date, not the real
>> version. So for instance libtiff 3.9.7 has it defined to 201209
23 matches
Mail list logo
