binkert
Sent: Wednesday, November 12, 2008 4:42 PM
To: Beckmann, Brad
Cc: M5 Developer List
Subject: Re: [m5-dev] changeset in m5: style: clean up the Packet
stuff
The VALID_DST change is correct, but I don't quite understand the
allocate() change. You got rid of the assertion that there is valid
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
nathan
binkert
Sent: Wednesday, November 12, 2008 4:42 PM
To: Beckmann, Brad
Cc: M5 Developer List
Subject: Re: [m5-dev] changeset in m5: style: clean up the Packet
stuff
The VALID_DST change is correct, but I don't quite
Isn't the assertion backwards? Looks to me that if data is nonzero
you're asserting that neither STATIC_DATA nor DYNAMIC_DATA is set.
Don't you need a '!' in that assertion? Or change it to flags.any()
or whatever the right operator is?
You're right of course. It should be flags.any().
This diff went way beyond style cleanup. Unfortunately, I didn't
remember to update the commit message. One of the big things I did
was get rid of all of the individual boolean variable flags and create
a single flags variable. I also made all of the flag values static
members of their classes
I thought that we had agreed to always use braces for control structures
(for, if, while, etc.) since that makes it easier to add/remove lines
without worrying about adding/removing braces too. I don't see it mentioned
either way on the coding style page, but I know I've developed the habit of
Also, please make these sorts of large scale formatting changes
judiciously. There's a large collection of patches out there and it can
be non-trivial to keep them applying correctly.
Gabe
Steve Reinhardt wrote:
I thought that we had agreed to always use braces for control
structures (for,
I thought that we had agreed to always use braces for control structures
(for, if, while, etc.) since that makes it easier to add/remove lines
without worrying about adding/removing braces too. I don't see it mentioned
either way on the coding style page, but I know I've developed the habit
I don't really have a strong opinion either way; the #1 thing is that we
should agree and get it down on the wiki page so that these style updates
converge rather than oscillating.
Agreed. What do you think about my above statement? If the whole
expression fits in two lines, no
I think that sounds fine. Does no braces required also mean no braces
allowed, or is that something left up to the implementers discretion? I
think it should be optional rather than forbidden.
I'd agree with optional.
___
m5-dev mailing list
On Sat, Sep 27, 2008 at 9:35 PM, nathan binkert [EMAIL PROTECTED] wrote:
I think that sounds fine. Does no braces required also mean no braces
allowed, or is that something left up to the implementers discretion? I
think it should be optional rather than forbidden.
I'd agree with
Optional is OK with me, but in that case it's not something that should be
fixed in a style update.
True, my bad. I was just going really fast.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
yeah, I just did this quickly and I guess I missed switch in my
regexp. I just committed fix.
I've been toying around with an emacs script to go through and fix up
some of the basics.
It might be worth spending some effort to get a beautifier working.
There's one that seems to still be getting
I really hope this isn't going to make applying all my patches significantly
harder...
Gabe
Quoting Ali Saidi [EMAIL PROTECTED]:
changeset 3af77710f397 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=3af77710f397
description:
style: Remove non-leading tabs
run expand on the patch files before trying to apply them...
Everything should work fine.
Ali
On Sep 10, 2008, at 4:44 PM, [EMAIL PROTECTED] wrote:
I really hope this isn't going to make applying all my patches
significantly
harder...
Gabe
Quoting Ali Saidi [EMAIL PROTECTED]:
we've hacked on remote_gdb so much that preserving the tabs wouldn't
really help.
Ali
On Sep 10, 2008, at 4:48 PM, [EMAIL PROTECTED] wrote:
Also I notice some of these are changes to the *bsd copyrights on
some files,
for instance the remote_gdbs. We probably shouldn't change those.
On the topic of style violations, I've seen an increasing number of 'if('
and 'for(' (with no space) creeping in (see below). Another thing I've seen
that irritates me (but isn't officially banned by the style code ... yet
...) is C++-style comments with no space between the // and the comment:
On the topic of style violations, I've seen an increasing number of 'if('
and 'for(' (with no space) creeping in (see below). Another thing I've seen
that irritates me (but isn't officially banned by the style code ... yet
...) is C++-style comments with no space between the // and the
17 matches
Mail list logo
