Alex Henrie wrote:
> -WideCharToMultiByte( CP_ACP, 0, msgW, -1, msg, sizeof(msg), NULL,
> NULL );
> +WideCharToMultiByte( CP_UTF8, 0, msgW, -1, msg, sizeof(msg), NULL,
> NULL );
> MESSAGE( "wine: %s", msg );
Try CP_UNIXCP intead.
--
Dmitry.
On Tue, 18 Oct 2011 16:14:36 +0200, Alexandre Julliard wrote:
> Akihiro Sagawa writes:
>
> > @@ -1,7 +1,7 @@
> > EXTRADEFS = -D_GDI32_
> > MODULE= gdi32.dll
> > IMPORTLIB = gdi32
> > -IMPORTS = advapi32
> > +IMPORTS = advapi32 user32
>
> You don't want to import user32 from gdi32.
Lo
On 10/18/2011 07:37 PM, Vitaliy Margolen wrote:
So any admins actually watching and want to bad roberbdib3a on forum?
Also why aren't every moderator has these rights to block spammers, since we
have only one forum.
So no takers? I'm guessing we need more forum admins then, so more timezones
c
So any admins actually watching and want to bad roberbdib3a on forum?
Also why aren't every moderator has these rights to block spammers, since we
have only one forum.
- Vitaliy
http://bugs.winehq.org/show_bug.cgi?id=23124
Could someone tell me if the attached patch would actually work?
It does compile and works correctly with LANG=en_PH.utf-8 but I'm don't
know that:
1. Using an "ln -s" is acceptable, nor if it will work given some file
systems may be unable to use
On Tue, Oct 18, 2011 at 16:34, wrote:
> This is an experimental automated build and test service.
> Please feel free to ignore this email while we work the kinks out.
>
> For more info about this message, see http://wiki.winehq.org/BuildBot
>
> The Buildbot has detected a failed build on builder
On Tuesday 18 October 2011 20:12:35 Stefan Dösinger wrote:
> On Tuesday 18 October 2011 19:36:33 Stefan Dösinger wrote:
> > I felt that merging the tests to test all format and pool combinations
> > would cause needlessly complicated
>
> With a few simplifications like skipping all tests without d
I've added a suppression for this already to
http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-suppressions
It looks benign, but it's annoying because the suppression it needs
is so wide. I wonder if the gcc bug on ubuntu 11.10 is why there's
no useful backtrace there...
S
Am Dienstag 18 Oktober 2011, 22:28:26 schrieb Uwe Bonnes:
> Hello,
>
> while hunting down why a drop down box didn't offer me the serial port I
> configured, I stumbled across Stefans proposal from Summer 09. The patch
> still applied cleanly, and after setting up hal and the hal development
> lib
2011/10/18 André Hentschel
> Am 18.10.2011 10:45, schrieb Damjan Jovanovic:
> > This tool compiled all 35000 or so commits from Wine 1.0 to around 4th
> October 2011 in only 7 days, generating a Git repository of Wine binaries
> that's only 26 gigabytes in size. Regression testing with binaries i
Hello,
while hunting down why a drop down box didn't offer me the serial port I
configured, I stumbled across Stefans proposal from Summer 09. The patch
still applied cleanly, and after setting up hal and the hal development
library, the progarm worked as expected.
What is the status of that prop
On 18/10/11 6:35 PM, Alexandre Julliard wrote:
Ken Sharp writes:
So any changes made should be in both the .rc files AND the .po files
to keep them in sync?
I resynchronize en_US.po when committing, so you don't need to submit
that part.
http://source.winehq.org/patches/data/79974 This s
On 18/10/11 6:35 PM, Alexandre Julliard wrote:
Ken Sharp writes:
So any changes made should be in both the .rc files AND the .po files
to keep them in sync?
I resynchronize en_US.po when committing, so you don't need to submit
that part.
Excellent, thanks Alexandre, that's what I was loo
Am 18.10.2011 10:45, schrieb Damjan Jovanovic:
> This tool compiled all 35000 or so commits from Wine 1.0 to around 4th
> October 2011 in only 7 days, generating a Git repository of Wine binaries
> that's only 26 gigabytes in size. Regression testing with binaries is a
> pleasure: it takes only
On Tuesday 18 October 2011 19:36:33 Stefan Dösinger wrote:
> I felt that merging the tests to test all format and pool combinations
> would cause needlessly complicated
With a few simplifications like skipping all tests without dynamic textures it
turns out okish. It's not too pretty. There are st
On Tuesday 18 October 2011 17:37:09 Henri Verbeet wrote:
> That's not really what I meant with "make this part of the test in
> patch 3/7". The point is that test_lockrect_offset() is about the
> offset calculation, not so much about what valid rectangles for block
> based formats are. And it proba
Ken Sharp writes:
> So any changes made should be in both the .rc files AND the .po files
> to keep them in sync?
I resynchronize en_US.po when committing, so you don't need to submit
that part.
--
Alexandre Julliard
julli...@winehq.org
On Tue, Oct 18, 2011 at 10:26, Dmitry Timoshkov wrote:
> Austin English wrote:
>
>
>> > Reverting a patch in latest git is not always possible, instead it's
>> > a very useful test to revert the patch at the suspected regression point
>> > and see if that really helps.
>>
>> That still doesn't re
Austin English wrote:
> > Reverting a patch in latest git is not always possible, instead it's
> > a very useful test to revert the patch at the suspected regression point
> > and see if that really helps.
>
> That still doesn't require a full regression test, just:
> $ git checkout -f $SHA1SUM
On Tue, Oct 18, 2011 at 09:01, Dmitry Timoshkov wrote:
> Damjan Jovanovic wrote:
>> > Moreover, often users get asked 'does reverting commit ' help? Without
>> > performing a proper regression test it's impossible to asnwer that
>> > question.
>> >
>> >
>> Reverting a commit in the latest git
Damjan Jovanovic wrote:
> > Moreover, often users get asked 'does reverting commit ' help? Without
> > performing a proper regression test it's impossible to asnwer that
> > question.
> >
> >
> Reverting a commit in the latest git is just 1 round of
> patch+configure+make+run, and reverting to
On 18/10/11 17:05, Alexandre Julliard wrote:
Ken Sharp writes:
Okay that should be simple enough, but what is po/en_US.po for then?
Won't the translations in en_US.po override any US translations in the
.rc files?
Yes, but in general they should be identical. We have en_US.po because
there
Ken Sharp writes:
> Okay that should be simple enough, but what is po/en_US.po for then?
> Won't the translations in en_US.po override any US translations in the
> .rc files?
Yes, but in general they should be identical. We have en_US.po because
there are cases where strings need to be different
On Tue, Oct 18, 2011 at 2:32 PM, Dmitry Timoshkov wrote:
> Henri Verbeet wrote:
>
> > On 18 October 2011 10:45, Damjan Jovanovic wrote:
> > > (especially during "reverse regression testing"), users find it too
> long and
> > > technical, and only a small minority of regressions are ever bisecte
On 18 October 2011 12:43, Stefan Dösinger wrote:
> Changes: Check for dynamic texture support, moved the format-specific tests to
> this patch.
>
That's not really what I meant with "make this part of the test in
patch 3/7". The point is that test_lockrect_offset() is about the
offset calculation,
On 18/10/11 16:15, Frédéric Delanoy wrote:
On Tue, Oct 18, 2011 at 17:01, Francois Gouget wrote:
My understanding it that en.po contains the British translation and is
treated as just another translation. So instead of containing just the
strings that need to be different, all the other strin
On 18/10/11 16:01, Francois Gouget wrote:
On Tue, 18 Oct 2011, Ken Sharp wrote:
[...]
Okay that should be simple enough, but what is po/en_US.po for then? Won't the
translations in en_US.po override any US translations in the .rc files?
Currently it's 100% translated and I suspect all string
On Tue, Oct 18, 2011 at 17:01, Francois Gouget wrote:
> My understanding it that en.po contains the British translation and is
> treated as just another translation. So instead of containing just the
> strings that need to be different, all the other strings are copied as
> well by the translators
On Tue, 18 Oct 2011, Ken Sharp wrote:
[...]
> Okay that should be simple enough, but what is po/en_US.po for then? Won't the
> translations in en_US.po override any US translations in the .rc files?
Currently it's 100% translated and I suspect all strings are simply
copied as is:
2524 (100.0%) t
On 18/10/11 15:23, Alexandre Julliard wrote:
Ken Sharp writes:
From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001
From: Ken Sharp
Date: Sat, 15 Oct 2011 03:50:43 +0100
Subject: [PATCH] po: Update English (US) translation
There's no translation to update, the rc files a
Ken Sharp writes:
> From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001
> From: Ken Sharp
> Date: Sat, 15 Oct 2011 03:50:43 +0100
> Subject: [PATCH] po: Update English (US) translation
There's no translation to update, the rc files are already en_US. If the
strings need chang
Akihiro Sagawa writes:
> @@ -1,7 +1,7 @@
> EXTRADEFS = -D_GDI32_
> MODULE= gdi32.dll
> IMPORTLIB = gdi32
> -IMPORTS = advapi32
> +IMPORTS = advapi32 user32
You don't want to import user32 from gdi32.
--
Alexandre Julliard
julli...@winehq.org
On Tue, Oct 18, 2011 at 13:42, Damjan Jovanovic wrote:
> If you are talking about using compiling with ccache instead of the binary
> repository, "configure" alone is > 40 seconds
configure -C option can speed it up a lot
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=14979
Your paranoid android
On 10/18/11 15:22, Marvin wrote:
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.
Henri Verbeet wrote:
> On 18 October 2011 10:45, Damjan Jovanovic wrote:
> > (especially during "reverse regression testing"), users find it too long and
> > technical, and only a small minority of regressions are ever bisected. And
> Not true. Even for the regressions that are still open it's c
On 18 October 2011 13:42, Damjan Jovanovic wrote:
> There's currently another 182 regressions that were closed "ABANDONED".
> Maybe if regression testing was easier and faster, people wouldn't abandon
> them?
>
Maybe. That's 182 closed ABANDONED, out of 2590 total closed, so
that's on the order of
Exciting!
On 10/18/2011 01:45 AM, Damjan Jovanovic wrote:
> I haven't figured out how to make the binaries available to users. Few
> users can clone a 26 gigabyte repository, and even fewer places can
> serve that much to multiple users. Maybe Git can compress it further?
> The other idea I had is
On Tue, Oct 18, 2011 at 12:08 PM, Henri Verbeet wrote:
> On 18 October 2011 10:45, Damjan Jovanovic wrote:
> > (especially during "reverse regression testing"), users find it too long
> and
> > technical, and only a small minority of regressions are ever bisected.
> And
> Not true. Even for the
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=14970
Your paranoid android
On 18 October 2011 10:45, Damjan Jovanovic wrote:
> (especially during "reverse regression testing"), users find it too long and
> technical, and only a small minority of regressions are ever bisected. And
Not true. Even for the regressions that are still open it's currently
276 bisected vs. 99 no
On Tue, Oct 18, 2011 at 10:45 AM, Damjan Jovanovic wrote:
> Hi
>
> Since the beginning, I've had issues with regression testing. Despite the
> fact it's very useful, it takes forever, it's easy to make a mistake
> (especially during "reverse regression testing"), users find it too long and
> techn
Hi
Since the beginning, I've had issues with regression testing. Despite the
fact it's very useful, it takes forever, it's easy to make a mistake
(especially during "reverse regression testing"), users find it too long and
technical, and only a small minority of regressions are ever bisected. And
43 matches
Mail list logo
