Hi Dan,
thanks for your response.
On 09/07/10 14:22, Dan Kegel wrote:
> Thanks for sending that patch.
>
> It seems your editor stripped whitespace from the ends of lines,
Having one's editor take care of trailing whitespace is fairly standard
practice isn't it?
Can I guess that having trailin
If you are saying they won't accept a patch because of this, I'd be
tempted to say "for f**ks sake can I be bothered with such pettiness?",
but I suppose "for the greater good" I'd resubmit.
It is common behaviour for large scale projects, e.g. the Linux Kernel
applies this rule, too. If you fr
On Thu, Jul 8, 2010 at 7:50 PM, Eliot Blennerhassett
wrote:
>> It seems your editor stripped whitespace from the ends of lines,
>
> Having one's editor take care of trailing whitespace is fairly standard
> practice isn't it?
Not when working on Wine code.
> Can I guess that having trailing white
Thanks for sending that patch.
It seems your editor stripped whitespace from the ends of lines,
causing three whitespace-only hunks on the end of your patch.
Please don't do that; Wine deveopers frown on unrelated whitespace changes.
You might have better luck getting your change in if you includ
Dear All:
Sorry to bother - I just ran into something quite curious in terms of a
Wine-specific feature that is certainly not matched in Windows XP and
was wondering what its purpose was...
Also, should I use todo_wine to test for this, or is there a better way
since this seems something that obv
Upon request, I've added a couple of VMs for your testing pleasure:
WXPPROARSP3 - Windows XP Pro Arabic SP3
WXPPROJASP3 - Windows XP Pro Japanese SP3
WXPPRORUSP3 - Windows XP Pro Russian SP3
WXPPROZHSP3 - Windows XP Pro Chinese simplified SP3
I must say, installing these VMs with their non-Wester
Am 08.07.2010 21:31, schrieb Hans Leidekker:
> On Thu, 2010-07-08 at 21:19 +0200, André Hentschel wrote:
>
>> +@ stdcall SHGetPropertyStoreFromParsingName(str ptr long ptr ptr)
>
> The first parameter should be wstr.
>
>
true, and i thought i did...
thx
--
Best Regards, André Hentschel
On Thu, 2010-07-08 at 21:19 +0200, André Hentschel wrote:
> +@ stdcall SHGetPropertyStoreFromParsingName(str ptr long ptr ptr)
The first parameter should be wstr.
Wade is a new intern here at CodeWeavers that we are training how to do
winehacking.
We totally expect that these patches get set to deferred because of the
wine 1.2 release. But I wanted to go through the process of how to send
patches while the patches where fresh in his mind.
So when the
Wade:
Does this fix a known bug?
We are indeed in code freeze and this is a big patch...
James McKenzie
-Original Message-
>From: Wade Gobel
>Sent: Jul 8, 2010 7:27 AM
>To: wine-patches
>Subject: [1/2] gdiplus: Fixed GdipFillClosedCurve2 and GdipFillClosedCurve2I
>in the case tha
On 8 July 2010 18:02, Paul Vriens wrote:
> On 07/08/2010 06:50 PM, Jimmy O'Regan wrote:
>>
>> On 8 July 2010 14:52, Ken Sharp wrote:
>>>
>>
>> My Irish (Irish, not "Gaelic") has been steadily deteriorating since I
>> left school, but it's painfully clear that you don't speak a word of
>> the lang
On 07/08/2010 06:50 PM, Jimmy O'Regan wrote:
On 8 July 2010 14:52, Ken Sharp wrote:
My Irish (Irish, not "Gaelic") has been steadily deteriorating since I
left school, but it's painfully clear that you don't speak a word of
the language.
+IDS_FAILED, "Ag tosú Wordpad Theip"
Should be s
On Thursday 08 July 2010 07:09:58 pm Vitaliy Margolen wrote:
> On 07/06/2010 03:15 PM, Paul Chitescu wrote:
> > Changelog:
> > ntdll: Stub system service requests in i386 mode (Int 2E, SYSENTER,
SYSCALL)
> >
> > +WINE_FIXME( "(0x%02X, %p): stub\n", index, param_block );
> > +W
On 8 July 2010 14:52, Ken Sharp wrote:
>
My Irish (Irish, not "Gaelic") has been steadily deteriorating since I
left school, but it's painfully clear that you don't speak a word of
the language.
+IDS_FAILED, "Ag tosú Wordpad Theip"
Should be something like 'Theip ar Wordpad a thosú'; what y
On 07/06/2010 03:15 PM, Paul Chitescu wrote:
> Changelog:
> ntdll: Stub system service requests in i386 mode (Int 2E, SYSENTER,
> SYSCALL)
>
> +WINE_FIXME( "(0x%02X, %p): stub\n", index, param_block );
> +WINE_TRACE( "INT 2E at 08%x\n", context->Eip );
Any particular reason
On 7/8/2010 18:27, Wade Gobel wrote:
---
dlls/gdiplus/graphics.c |8 ++-
dlls/gdiplus/tests/graphics.c | 135
+
2 files changed, 142 insertions(+), 1 deletions(-)
Hi, Wade.
Patches are broken by your mail client. You could attach or setup
On Wed, Jul 7, 2010 at 10:41 PM, James McKenzie
wrote:
> Misha Koshelev wrote:
>>>
>>> Misha Koshelev wrote:
>>>
Ok per Dan's comments back to >>>
>>>
>>> Misha:
>>>
>>> Alexandre rejects 'white space' changes, that is changes that fix
>>> indentation, remove extraneous or trailing
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=3232
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=3231
Your paranoid android.
writes:
> C:\>d:
> D:\foo>d:\bar\zot\kernel32_test.exe volume # from testbot job #3225
> volume.c:328: Test failed: GetVolumeInformationA w/o '\' did not fail, last
> error 3735928559
> volume: 285 tests executed (0 marked as todo, 1 failure), 0 skipped.
>
> I.e. the test fails (GetVolumeInforma
Hi,
>That's only moving the bug around.
Indeed. It just moves the todo_wine from one side to the other.
> We have tests for the current
>behavior, any further improvement must keep the existing tests working.
I dispute the correctness of the tests. Here's what I get
on a real (as opposed to virt
wrote:
> A) Bug compatibility => Behavioural compatibility => drop existing
>code and try to mimic native's behaviour as closely as possible.
> B) PAUSE and RESUME is a useful extension not present in native, keep it
>as long as no app is affected by this difference in behaviour.
A basic
On 8 July 2010 10:32, wrote:
> What do you think?
> A) Bug compatibility => Behavioural compatibility => drop existing
> code and try to mimic native's behaviour as closely as possible.
> B) PAUSE and RESUME is a useful extension not present in native, keep it
> as long as no app is affected
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=3223
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=3224
Your paranoid android.
Hi,
Unlike mciwave, the native mciseq MIDI player does not know the
MCI_RESUME command. It instead returns MCIERR_UNSUPPORTED_FUNCTION.
Tests with notification suggest that MCI_PAUSE actually aborts the
player, much like MCI_STOP. It's a different behaviour than mciwave.
(You can always "resume"
writes:
> The tests prove that not all calls without a trailing slash must fail.
> So until we know more precisely the exact conditions, I feel it's
> better to revert to the old behaviour that allowed the copy
> protection scheme to work.
That's only moving the bug around. We have tests for the
27 matches
Mail list logo
