"Ken Thomases" wrote:
If you as a user want to override the language that Wine displays,
you can set LC_MESSAGES in your environment rather than LANG.
Setting LC_ALL would achieve that, plus override the various other
locale categories. Set LANG is the wrong approach, in my opinion.
In the m
Ken Thomases wrote:
> Setting LC_ALL would achieve that, plus override the various other locale
> categories. Set LANG is the wrong approach, in my opinion.
However this is not the way Wine works on all other platforms. Keeping
everything in sync is more appropriate here. Or modify global Wine beh
Pie's in the oven, time for another winetricks release.
Changes in this version:
Add experimental dotnet35 verb
Add IE7 verb. Based on a patch by Hans Leidekker.
Add verbs alsa, audioio, coreaudio, esound, jack, nas, oss to override
sound driver
Add verbs backbuffer, fbo, pbuffer for setting offs
On Wed, Nov 25, 2009 at 5:48 PM, Austin English wrote:
> Sure, that would be an option if the system has e-mail configured, but
> since I use webmail, I went with the 'sit and wait' method. For other
> projects that script would obviously need a different strategy (though
> I don't other projects
2009/11/25 Austin English :
> On Wed, Nov 25, 2009 at 4:45 PM, Marcus Meissner
> wrote:
>> On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote:
>>> On Wed, Nov 25, 2009 at 12:08 PM, Austin English
>>> wrote:
>>> > The other neat thing is that it will run git fetch in a loop every 30
>
On Wed, Nov 25, 2009 at 4:45 PM, Marcus Meissner wrote:
> On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote:
>> On Wed, Nov 25, 2009 at 12:08 PM, Austin English
>> wrote:
>> > The other neat thing is that it will run git fetch in a loop every 30
>> > minutes (again, overridable), so
On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote:
> On Wed, Nov 25, 2009 at 12:08 PM, Austin English
> wrote:
> > The other neat thing is that it will run git fetch in a loop every 30
> > minutes (again, overridable), so that you can run it in the morning
> > while waiting for AJ to
On Wed, Nov 25, 2009 at 5:24 PM, Steven Edwards wrote:
>> To make a Continuous Integration Service around it it should run as a
>> background process under another user out of init in a Xnest/VNC
>> session. I am thinking something like a winecis user which would run
>> these scripts, fetch and th
On Wed, Nov 25, 2009 at 5:21 PM, Steven Edwards wrote:
> It would be nice to dummy email account subscribed to the commit
> messages that it could poll to trigger the checkout, build, test
> cycle.
>
> To make a Continuous Integration Service around it it should run as a
> background process under
On Wed, Nov 25, 2009 at 12:08 PM, Austin English
wrote:
> The other neat thing is that it will run git fetch in a loop every 30
> minutes (again, overridable), so that you can run it in the morning
> while waiting for AJ to commit. Once commits are made to the git
> master branch (but not stable),
I'm not sure it's very appropriate to add this yet, since the extension isn't
finalized. Until it's finalized, there could be changes that modify the API
calls (I don't expect changes, but it's best to err on the side of caution, I
think).
The alBufferDataStatic patch is fine, though.
On Wednesday 25 November 2009 19:02:08 Ken Thomases wrote:
> On Nov 25, 2009, at 11:13 AM, Nate Gallaher wrote:
> > Ken Thomases wrote:
> >> One important reason to avoid whitespace-only changes is it makes
> >> git-blame essentially useless for finding the real source of functional
> >> changes.
>
The MSDN:
http://msdn.microsoft.com/en-us/library/aa364980(VS.85).aspx
states that GetLongPathNameW returns the length of the string
required to hold the pathname if the buffer is too small to hold
the path. In the case where the buffer is too small, the filename
should not be stored in the buf
Paul Vriens wrote:
On 11/25/2009 05:39 PM, Jacek Caban wrote:
Hi Paul,
Paul Vriens wrote:
Hi Jacek,
You are the original author of these tests. Is there any reason the
"test3.manifest" name is reused?
The tests currently crash (intermittently on some) on Vista+ and with
the attached patch th
On 11/25/2009 05:39 PM, Jacek Caban wrote:
Hi Paul,
Paul Vriens wrote:
Hi Jacek,
You are the original author of these tests. Is there any reason the
"test3.manifest" name is reused?
The tests currently crash (intermittently on some) on Vista+ and with
the attached patch things seem to get bet
On Nov 25, 2009, at 11:13 AM, Nate Gallaher wrote:
> Ken Thomases wrote:
>> One important reason to avoid whitespace-only changes is it makes git-blame
>> essentially useless for finding the real source of functional changes.
>>
>
> But is that really important? git-bisect would put you on the
On Wed, Nov 25, 2009 at 12:08 PM, Austin English
wrote:
> On Wed, Nov 25, 2009 at 10:33 AM, Jeremy White wrote:
>> As promised, I'm attaching the script I'm using.
>
> I really wish you had said something to me before..I've been cleaning
> my script up, with some help from Vincent. It's pretty si
Ken Thomases wrote:
One important reason to avoid whitespace-only changes is it makes git-blame
essentially useless for finding the real source of functional changes.
But is that really important? git-bisect would put you on the other
side of any whitespace changes, and a prudent bug-hunter
On Wed, Nov 25, 2009 at 10:33 AM, Jeremy White wrote:
> So I have done my penance for failing to set up
> a cron to run testing. I've got routine testing
> going every night on 2 boxes. It seems solid.
>
> I see that many others have done this as well - test.winehq.org
> wine results are really
On Wednesday 25 November 2009 06:36:46 pm Paul Chitescu wrote:
> Changelog:
> wineserver: Added support for read/only Registry, similar to
> unprivileged
> users
> [...]
How to test (if it gets accepted):
chmod -w $WINEPREFIX/system.reg $WINEPREFIX/userdef.reg
What to expect:
Major br
On Nov 24, 2009, at 7:52 AM, Charles Davis wrote:
> I just realized something. The reason Wine doesn't respect LANG is that
> it overrides the LC_MESSAGES setting if it is set to the default. It
> will be set to the default if there is no LC_MESSAGES in the
> environment. So we don't want to overr
Hi Paul,
Paul Vriens wrote:
Hi Jacek,
You are the original author of these tests. Is there any reason the
"test3.manifest" name is reused?
The tests currently crash (intermittently on some) on Vista+ and with
the attached patch things seem to get better. I'm just renaming one of
the manife
So I have done my penance for failing to set up
a cron to run testing. I've got routine testing
going every night on 2 boxes. It seems solid.
I see that many others have done this as well - test.winehq.org
wine results are really looking good.
As promised, I'm attaching the script I'm using.
On Nov 25, 2009, at 9:13 AM, Nate Gallaher wrote:
> I understand the "preserve existing format" rule, particularly in cases of
> braces, inter-paren spacing, variable
> names, function names, and alignment, but I don't see the benefit of keeping
> 80-cols insanity around.
One important reason
Hi Jacek,
You are the original author of these tests. Is there any reason the
"test3.manifest" name is reused?
The tests currently crash (intermittently on some) on Vista+ and with
the attached patch things seem to get better. I'm just renaming one of
the manifest files so there are no dupli
Nikolay Sivov wrote:
or should I just fix the
one function I'm planning on touching? Or should I grit my teeth
and ignore the style issues
entirely?
Yes, in most cases. If you plan to rework the whole file with
functional patches feel free to touch
formatting a bit. The common rule is to pre
Nate/Nikolay:
Make sure that your patch has no white space errors and stay away from tabs,
unless the current file is using them.
git -apply should run without any errors.
Cleaning up whitespace errors outside of code you are fixing should be very
conservative. AJ likes it that way...
BTW, I
Nate Gallaher wrote:
I'm looking at working on a new area of wine (for me) and the file I'm
going to be working
with is rife with whitespace issues. Literal tabs are sprinkled
around and the 80-col limit
has been broken badly and often in easily fixable ways. I'm wondering
what the acceptable
I'm looking at working on a new area of wine (for me) and the file I'm
going to be working
with is rife with whitespace issues. Literal tabs are sprinkled around
and the 80-col limit
has been broken badly and often in easily fixable ways. I'm wondering
what the acceptable
approach is to these
Some people reply on wine-patches to comment on patches. Those are a
safe bet to ignore when no patch is detected. There are a few examples
on the page.
J. Leclanche / Adys
On Wed, Nov 25, 2009 at 3:37 PM, Nate Gallaher
wrote:
> I'm not sure what you're asking. Are you trying to ignore wine-d
Is it possible to ignore the Re:'s that don't have a patch attached?
J. Leclanche / Adys
On Tue, Nov 24, 2009 at 10:23 PM, Austin English
wrote:
> On Tue, Nov 24, 2009 at 3:22 PM, James Mckenzie
> wrote:
>> Austin English wrote:
>>>Sent: Nov 24, 2009 2:09 PM
>>>To: Nate Gallaher
>>>Cc: wine
Roderick Colenbrander wrote:
> On Wed, Nov 25, 2009 at 3:46 AM, chris ahrendt wrote:
>> Roderick Colenbrander wrote:
>>> On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt wrote:
Ok going through and looking at the next failure in wine tests I found
this one :
If you look at
Am 24.11.2009 um 23:05 schrieb Michael Stefaniuc:
>>
> Stefan, let me guess, you just wanted to point him to
> http://wiki.winehq.org/USB ? ;)
Whaaa. Searching the wiki might have saved me lots of typing...
On Wed, Nov 25, 2009 at 3:46 AM, chris ahrendt wrote:
> Roderick Colenbrander wrote:
>> On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt wrote:
>>> Ok going through and looking at the next failure in wine tests I found this
>>> one :
>>>
>>>
>>> If you look at the code its:
>>>
>>>
>>> 779 co
34 matches
Mail list logo
