Aric Stewart wrote:
>
> It should return number of copied bytes. But it always returns required
> buffer size to receive all information.
> (originally by Kusanagi Kouichi ([EMAIL PROTECTED]) )
> ---
> dlls/imm32/imm.c | 207
> ++
> 1 files ch
While debugging some force-feedback issues ran into an interesting problem.
The size of one struct from include/linux differs between 32-bit and 64-bit.
That wouldn't be a major problem except that size is the part of the ioctl()
request. Which results in EINVAL.
In more details:
input.h:
#defi
On 8/11/08, Ismael Barros <[EMAIL PROTECTED]> wrote:
> Actually the thread stuff is a very good idea, I'll take a look.
I tried launching each tests in a new thread, but a lot of tests
failures arise, sometimes even with segfaults or deadlocks. Looks like
the original implementation of dplay doesn
Am Dienstag, den 12.08.2008, 10:58 -0700 schrieb Dan Kegel:
> The list is currently
> user32:msg.c
> user32:input.c
Same problems here. Metacity 2.23.21, compiled myself.
> d3d9:visual.c
> ddraw:visual.c
The last two are really nasty. Take a look at ddraw/tests/visual.c:2624.
It makes a kind o
2008/8/12 Dan Kegel <[EMAIL PROTECTED]>:
> On Tue, Aug 12, 2008 at 6:47 AM, <[EMAIL PROTECTED]> wrote:
>> couldn't you instead when the patchwatcher takes the patch it assigns it a
>> patch # and require if there is a patch dependency that the person put into
>> a comment REQ_PATCH: 123456,15456,
On Tue, Aug 12, 2008 at 1:39 PM, Adam Petaccia <[EMAIL PROTECTED]> wrote:
> What about checking for a string in the email like "patchwatchignore";
> if for some reason the patch is known to cause a failure the e-mail
> might read like:
>patchwatchignore
>This depends on Harald's pat
On Mon, 2008-08-11 at 22:24 -0700, Dan Kegel wrote:
> Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> > "Zachary Goldberg" <[EMAIL PROTECTED]> wrote:
> >
> >> Policy is that all patches should be independent, no?
> >
> > There is no such a policy. Dependent patches are marked as
> > 1/xx, 2/xx, ... x
So, one of the things one learns when writing a
patch robot is that flaky tests are very annoying.
Each time it gets a new git tree,
the robot does five baseline "make -k test" runs,
remembers the tests that fail, and doesn't penalize
patches for failing any of those tests. See
http://code.google
On Tue, Aug 12, 2008 at 10:29 AM, Reece Dunn <[EMAIL PROTECTED]> wrote:
> I use GMail to do something similar - tag mail I send to wine-patches
> with a 'wine-tracking' label, as well as the 'wine-patches' label it
> gets from the mailing list filter I have. This allows me to see all
> active patch
Am Dienstag, den 12.08.2008, 08:26 -0700 schrieb Dan Kegel:
> Yeah, I know. I fiddled with the colors for a while, but not very
> effectively.
> I'm partly color-blind, and am not really the best person to
> work on the look of the reports page. If somebody else would like
> to get the colors ri
On Mon, Aug 11, 2008 at 11:59 PM, Dmitry Timoshkov
<[EMAIL PROTECTED]> wrote:
> "Vijay Kiran Kamuju" <[EMAIL PROTECTED]> wrote:
>
>> +BOOL WINAPI ConvertToAutoInheritPrivateObjectSecurity(
>> +PSECURITY_DESCRIPTOR ParentDescriptor,
>> +PSECURITY_DESCRIPTOR CreatorDescriptor,
>> +
Michael Karcher <[EMAIL PROTECTED]> wrote:
>> Yes. I already changed the success message to make more sense,
>> and added background colors of green and red for success and failure.
> I dislike the implementation, while I like the idea. You now have:
>
> a:visited { color: #FF; }
> .fail { bac
>> Yes. I already changed the success message to make more sense,
>> and added background colors of green and red for success and failure.
> I dislike the implementation, while I like the idea. You now have:
>
> a:visited { color: #FF; }
> .fail { background color: #ff5050; }
>
> At least on m
On Tue, Aug 12, 2008 at 6:47 AM, <[EMAIL PROTECTED]> wrote:
> couldn't you instead when the patchwatcher takes the patch it assigns it a
> patch # and require if there is a patch dependency that the person put into
> a comment REQ_PATCH: 123456,15456, etc.. ?
Yes, perhaps if patchwatcher catches
Am Montag, den 11.08.2008, 17:34 -0700 schrieb Dan Kegel:
> Yes. I already changed the success message to make more sense,
> and added background colors of green and red for success and failure.
I dislike the implementation, while I like the idea. You now have:
a:visited { color: #FF; }
.fail
couldn't you instead when the patchwatcher takes the patch it assigns it a
patch # and require if there is a patch dependency? that the person put into a
comment REQ_PATCH: 123456,15456, etc.. ? That way when a diff is done for the
patch it would appear in the patch diff?
Then patchwatcher woul
"Ilya Shpigor" <[EMAIL PROTECTED]> wrote:
What is the difference between wpParent1 and wpParent2 besides slightly
different indentation and 1 superfluous 'break' statement?
> > - /* why do we notify to es->hwndParent, and we send this one to
> > GetParent()? */
> > + /* All notifies are send to
"Ilya Shpigor" <[EMAIL PROTECTED]> wrote:
> - /* why do we notify to es->hwndParent, and we send this one to GetParent()?
> */
> + /* All notifies are send to es->hwndParent
> + * except the WM_CTLCOLORSTATIC and WM_CTLCOLOREDIT.
> + * Its are send to the current parent.
> + */
> hbru
18 matches
Mail list logo
