On May 25, 2009, at 2:50 PM, Zach Welch wrote:

On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
On May 25, 2009, at 2:24 PM, Zach Welch wrote:

Further, you can argue with the following assertions -- only if you
can
show me a patch that proves them wrong:


Show me your patch, or let me commit mine.  This debate is silly.

Cheers,

Zach


It's interesting that every time a discussion about preferences comes
up, it typically ends with "Here's my patch. This is silly. My patch
already works, let's just commit it."  It's not like discussion is
painful or this issue is causing problems for anyone.  We're better
off coming up with an answer that everyone is OK with rather than just
defaulting to whatever patch shows up first.

Actually, these kinds of issues are very frustrating to me personally,
because they always end up being counterproductive.  This is why I am
maintaining the Style Guide.  I desperately want to hereafter resolve
this debate by shouting "RTFM and STFU"; anything else is time wasted.
The burden of proof lies on the person that lacks a patch in-hand.

Until these matters are fully resolved, the discussion does cause a
problem because it prevents us from moving forward with genuinely
productive work on the system.


It isn't counterproductive the first time the discussion happens. It's counterproductive when someone wants to go against the established convention. The burden is always on the person who is arguing for something different that the convention. In this case, it's both of us.


The opposing patch is attached.  As I already mentioned, it is large,
but the changes were done entirely with the following commands:

find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u16/uint16_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u32/uint32_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u64/uint64_t/g' {} \;

find . -name \*.[ch] -exec sed -i .old -e 's/_uint8_t/_uint8/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint16_t/_uint16/ g' {} \; find . -name \*.[ch] -exec sed -i .old -e 's/_uint32_t/_uint32/ g' {} \; find . -name \*.[ch] -exec sed -i .old -e 's/_uint64_t/_uint64/ g' {} \;

The first set just do a bulk rename of the types, but it also changes
function names.  Since it looks odd to include the _t in a function
name, the second set changes the pattern used for function names to
not include the _t.

I hate it.  You seriously want to make all of the functions that
referred to u16 or u32 to now refer to uint16 and uint32???  This was
_exactly_ what I meant when I said a patch would be hard to create.


It wasn't hard to create at all. Eight find and replaces is all it took. Less than 10 minutes.

Also, you do realize that the scope of these changes is _much_ more
likely to be disruptive to anyone with out-of-tree changes in progress?


Yup. It is. Sadly until we decide on all these various conventions, things are always going to be disruptive to those with out-of-tree changes. At least in this case, syncing with ToT is relatively simple. Using minimal change as an argument for is dangerous. Consider the local minimum effect. To get to a better solution, you might need to stir things up a bit in the short term. The question we need to be asking is "Do we do a big change now, or do we live with a non-standard type system?"

Are you insane or merely sadistic? :)


Neither and the smiley doesn't really help your case either. You're taking this _way_ too personal for something that is a relatively mundane discussion. The two sides have chimed in, patches have been provided, and a fair number of developers have commented. It's up to the majority to decide which way to go.

Cheers,

Zach



--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split it with him."
 -- Unsigned

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to