Sorry, I should have labelled this patch as "Try 2".
--
Andy.
Andrew Talbot writes:
> Changelog:
> oleaut32: Indentation Fix.
Please avoid reformatting hundreds of lines for no reason. Only fix the
parts where the indentation is actually incorrect.
--
Alexandre Julliard
julli...@winehq.org
Dmitry Timoshkov wrote:
> Andrew Talbot wrote:
>
>> Changelog:
>> gdi32: Indentation fix.
>
> Please keep 4 spaces indentation without tabs.
>
Thus far, I have fixed the bits of code that are misleadingly indented using
the same indentation regime as the sur
Andrew Talbot wrote:
> Changelog:
> gdi32: Indentation fix.
Please keep 4 spaces indentation without tabs.
--
Dmitry.
Francois Gouget writes:
> ---
>
> Start-of-line spaces are ignored in RC files.
That syntax is not supported by RC, so it's best avoided.
--
Alexandre Julliard
julli...@winehq.org
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:
>>>
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 spaces and tabs unless there is another change
needed. If there is a n
> 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 spaces and tabs unless there is
> another change neede
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 spaces and tabs unless there is another change
needed. If there is a needed change in this file, go
On Wed, Jul 7, 2010 at 15:55, Misha Koshelev wrote:
> Ok, sorry, fixed per Henri's _and_ James' comments.
>
> Misha
>
> p.s. If I can ask for a _huge_ favor, I read wine-devel online and I guess I
> miss some of the messages. If you guys wouldn't mind
> cc'ing me on my patches just in case much a
On Wed, Jul 07, 2010 at 10:28:17AM -0500, Misha Koshelev wrote:
> Ok per Dan's comments back to
> This is my last try on these patches unless I hear from Alexandre.
>
> Misha
> ---
> dlls/d3dx9_36/tests/mesh.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/
Andrew Talbot wrote:
> It's a tabs vs spaces thing, but it looks way out on my system.
>
You might wish to ignore this patch. I had my tab stops set to four spaces
instead of eight, which exaggerated the distortion.
--
Andy.
Alistair Leslie-Hughes wrote:
> Hi Andrew,
> I would do 1, and if you think that its wrong, add a comment email
> asking
> for double check.
>
> Best Regards
> Alistair Leslie-Hughes
Sounds good. Thanks, Alistair!
--
Andy.
"Andrew Talbot" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi All,
>
> I'm intending to "correct" some indentation anomalies, and I propose to do
> this in an "indiscriminate" way. In other words, I would set the
>
Hi All,
I'm intending to "correct" some indentation anomalies, and I propose to do
this in an "indiscriminate" way. In other words, I would set the
indentation to match what the code does now, without any interpretation of
what may have been intended. This means that
Maarten Lankhorst wrote:
> Some of wine's code is a mess with indentation, but alexandre won't
> commit indentation patches.
>
This explains some frustrations with patches. Do we have the policy on
the web?
> Cheers,
> Maarten
>
Jeff
On 10/01/2008, Maarten Lankhorst <[EMAIL PROTECTED]> wrote:
> Divan Burger schreef:
> > Hi,
> >
> > What is the preferred number of spaces of indentation? In
> > comdlg32/colordlg.c it is either one or three spaces and there are a
> > few places where there
Divan Burger schreef:
> Hi,
>
> What is the preferred number of spaces of indentation? In
> comdlg32/colordlg.c it is either one or three spaces and there are a
> few places where there is no indentation and where things are randomly
> indented or switches between amounts of inde
Hi,
What is the preferred number of spaces of indentation? In
comdlg32/colordlg.c it is either one or three spaces and there are a
few places where there is no indentation and where things are randomly
indented or switches between amounts of indentation.
What is the policy on when to change
On 6/1/07, James Hawkins <[EMAIL PROTECTED]> wrote:
On 6/1/07, Tom Spear <[EMAIL PROTECTED]> wrote:
> Here is part 2 of try 2. Just cleans up the indentation of my changes
> in the previous patch in this series.
>
I think you misunderstood what Dan meant about ind
On 6/1/07, Tom Spear <[EMAIL PROTECTED]> wrote:
Here is part 2 of try 2. Just cleans up the indentation of my changes
in the previous patch in this series.
I think you misunderstood what Dan meant about indentation changes.
You shouldn't have a patch that doesn't properly ind
On Thu, May 31, 2007 at 02:23:59PM -0500, Tom Spear wrote:
> I recall a few years back (2003?) There was a discussion about
> removing extra whitespace at the end of lines, and someone came up
> with a bash/sed script to look thru the entire wine tree, strip
> trailing whitespace, and then somehow
econd patch.
Right, which is the way the patch is already done, I just wanted to
see if making changes to the whitespace in other parts of the file
(via the 2nd patch, which changes the indentation of my additions)
would be considered random whitespace changes, or if it would be
helpful, because
Tom wrote:
Hi all, just curious, in my work on uninstaller, I am writing my
patches to where when indentation is changed, due to adding a for
loop, it is done in a separate patch file. I was wondering if it is
acceptable to make whitespace changes to other parts of the file in
that same patch
Hi all, just curious, in my work on uninstaller, I am writing my
patches to where when indentation is changed, due to adding a for
loop, it is done in a separate patch file. I was wondering if it is
acceptable to make whitespace changes to other parts of the file in
that same patch.. For
On 17/04/07, Juan Lang wrote:
Sorry for the late reply.
> > I'm working on schannel at the moment. schannel is not a regular SSP,
> > and the functions in wrapper.c can't load native. I've implemented the
> > proper loading code in my local tree and I'm sending it in obvious
> > pieces. no-op cl
On Saturday 14 April 2007 00:56, Yuval Fledel wrote:
> - the patch is a no-op.
While I like to do the same to functions I work on, is there any reason you
need to change this for wrapper.c? It hasn't been changed for quite a while
and seems feature complete.
Kai
Hi Kai,
Please reply-to-all ne
Sorry for the late reply.
> > I'm working on schannel at the moment. schannel is not a regular SSP,
> > and the functions in wrapper.c can't load native. I've implemented the
> > proper loading code in my local tree and I'm sending it in obvious
> > pieces. no-op cleanups is the first step.
I'm c
On Monday 16 April 2007 13:20, Yuval Fledel wrote:
> Please reply-to-all next time. I've found your reply on the archive.
Sure, sorry about that.
>
> I'm working on schannel at the moment. schannel is not a regular SSP,
> and the functions in wrapper.c can't load native. I've implemented the
> pro
On Saturday 14 April 2007 00:56, Yuval Fledel wrote:
> - the patch is a no-op.
While I like to do the same to functions I work on, is there any reason you
need to change this for wrapper.c? It hasn't been changed for quite a while
and seems feature complete.
Kai
--
Kai Blin,
WorldForge deve
On Sa, 2007-04-14 at 01:56 +0300, Yuval Fledel wrote:
> wrapper.c | 1252
> ++
> 1 file changed, 545 insertions(+), 707 deletions(-)
I have no Idea about the code in secur32.dll, but your Patch is much to
large.
I suggest to modify only
* On Thu, 10 Nov 2005, Dimi Paun wrote:
> * From: "Saulius Krasuckas" <[EMAIL PROTECTED]>
> >
> > No I won't, because then a diff in my editor looks wrong.
>
> This is a bit confusing at first because diff inserts a char
> at the beginning of the line.
Of course I understand this. I just don't
From: "Saulius Krasuckas" <[EMAIL PROTECTED]>
> No I won't, because then a diff in my editor looks wrong.
This is a bit confusing at first because diff inserts a char
at the beginning of the line. Don't worry about it, the source
will look right after applying it. You will get used to it
soon enou
Saulius Krasuckas wrote:
* On Wed, 9 Nov 2005, Ivan Leo Puoti wrote:
* Saulius Krasuckas wrote:
The question isn't about world wide definition, it's about preference inside
Wine project. But OK, I will use tabs in a tabby files.
Please use spaces, we can't get rid of existing t
* On Wed, 9 Nov 2005, Ivan Leo Puoti wrote:
> * Saulius Krasuckas wrote:
> >
> > The question isn't about world wide definition, it's about preference inside
> > Wine project. But OK, I will use tabs in a tabby files.
>
> Please use spaces, we can't get rid of existing tabs but let's not make
>
Saulius Krasuckas wrote:
The question isn't about world wide definition, it's about preference
inside Wine project. But OK, I will use tabs in a tabby files.
Please use spaces, we can't get rid of existing tabs but let's not make things
worse.
Ivan.
* On Tue, 8 Nov 2005, Dmitry Timoshkov wrote:
> * "Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
> >
> > OK, and what tab size should I assume when I see it in simple one
> > level indent -- 4 or 8 space characters?
>
> Tab is 8 characters by definition.
The question isn't about world wide defi
"Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
> OK, and what tab size should I assume when I see it in simple one level
> indent -- 4 or 8 space characters?
Tab is 8 characters by definition.
--
Dmitry.
* On Tue, 8 Nov 2005, Alexandre Julliard wrote:
> * Saulius Krasuckas <[EMAIL PROTECTED]> writes:
> >
> > Will my patches be let into the tree if I will submit such no-op
> > changes (one patch for one file) from time to time just before normal,
> > operational patches.
>
> No, please don't do
Saulius Krasuckas <[EMAIL PROTECTED]> writes:
> Will my patches be let into the tree if I will submit such no-op changes
> (one patch for one file) from time to time just before normal, operational
> patches.
No, please don't do that.
--
Alexandre Julliard
[EMAIL PROTECTED]
Hello,
I'd like to get rid of tabs I encounter when reading existing Wine code.
Will my patches be let into the tree if I will submit such no-op changes
(one patch for one file) from time to time just before normal, operational
patches.
Michael Stefaniuc <[EMAIL PROTECTED]> writes:
> Well, it should be pretty easy to write a short smatch script to find
> that occurences. Afair the smatch guys wrote one for the Linux kernel
> which would need only small adaptations. And coincidently i have this
> weekend a long flight trip on my
Hi,
On Mon, Jan 24, 2005 at 09:02:56AM +0100, Rolf Kalbermatter wrote:
> On Sat, Jan 22, 2005 at 05:16:45PM +, Mike Hearn wrote:
>
> > Given that it can be quite complex and introduce new bugs, and given that
> > it's really quite a useless feature IMHO as modern Linux boxes will hang
> > the
On Sat, Jan 22, 2005 at 05:16:45PM +, Mike Hearn wrote:
> Given that it can be quite complex and introduce new bugs, and given that
> it's really quite a useless feature IMHO as modern Linux boxes will hang
> themselves in swap hell before returning NULL from malloc I don't think
> this should
Mike Hearn wrote:
OOM safety is a bit complicated, you have to properly unwind the stack and
restore state as you go - for instance the last patch I submitted fixed a
bug where OOM would not cause the loop to terminate, but I forgot to free
some data as we returned up the stack.
Given that it can
On Sat, Jan 22, 2005 at 05:16:45PM +, Mike Hearn wrote:
> Given that it can be quite complex and introduce new bugs, and given that
> it's really quite a useless feature IMHO as modern Linux boxes will hang
> themselves in swap hell before returning NULL from malloc I don't think
> this should
On Sun, 23 Jan 2005 10:33:38 +0100, Michael Stefaniuc wrote:
> I thought more of checking the return value of HeapAlloc/HeapRealloc to
> make sure it's not NULL. This would be easy to do. What you proposed is
> too complicated.
Well, what happens if it is NULL? You can print an error and then re
Mike Hearn wrote:
On Fri, 21 Jan 2005 22:02:00 +0100, Michael Stefaniuc wrote:
Well, it should be pretty easy to write a short smatch script to find
that occurences. Afair the smatch guys wrote one for the Linux kernel
which would need only small adaptations.
OOM safety is a bit complicated, you
On Fri, 21 Jan 2005 22:02:00 +0100, Michael Stefaniuc wrote:
> Well, it should be pretty easy to write a short smatch script to find
> that occurences. Afair the smatch guys wrote one for the Linux kernel
> which would need only small adaptations.
OOM safety is a bit complicated, you have to pro
Alexandre Julliard wrote:
Mike McCormack <[EMAIL PROTECTED]> writes:
I thought that crashing on out of memory conditions was a valid method
of error handling in the Julliard handbook of coding, so I removed a
pointless check :)
If we're going to mandate proper checking of memory allocation, then
w
Mike McCormack <[EMAIL PROTECTED]> writes:
> I thought that crashing on out of memory conditions was a valid method
> of error handling in the Julliard handbook of coding, so I removed a
> pointless check :)
>
> If we're going to mandate proper checking of memory allocation, then
> we need to mak
Mike McCormack <[EMAIL PROTECTED]> writes:
> -if(szFilePath) {
> +if( szFilePath )
> +{
> len = MultiByteToWideChar( CP_ACP, 0, szFilePath, -1, NULL, 0 );
> szwFilePath = HeapAlloc( GetProcessHeap(), 0, len*sizeof(WCHAR) );
> -if( !szwFilePath)
> -
Alexandre Julliard wrote:
Does your coding style also forbid proper error checking, or is there
another reason for removing that check?
I thought that crashing on out of memory conditions was a valid method
of error handling in the Julliard handbook of coding, so I removed a
pointless check :)
53 matches
Mail list logo
